JPz'log Coin Coin and Plop da Plop

Thoughts on F/OSS (10/10): governance

This is part of a 10 blog posts series on F/OSS thoughts, extracted from a talk that I gave recently.

Yes, "governance" is a word that sounds so boring. Opensource is all about fun, right?

Well, you still need to think about it, even if your project does not define a formal 10 pages long governance processes document. Quickly, there are the main few things that you should think about on the governance of your project.

First of all, you need to be able to categorize the people that gravitate around the project and the roles they have. Especially, you will need rules and processes for people to become commiters to your project.

The spontaneous free love / free participation vision of F/OSS theoricians does not work in practice, so there need to be rules, even simple, just to make sure that a coherent vision and set of values are maintained.

Intellectual property is important. Especially, one important question is to know if developers and contributors give their copyright away to you, if they share it with you, or if they keep it for themselves. This is less important with liberal licenses though.

You may also need to balance patents (which are evil) and trademarks (which are okay). Don't be surprised though if some F/OSS fanatics do not understand the rationale behind having trademarks and make silly things

This post marks the end of this 10 blog posts series on F/OSS thoughts. I hope you enjoyed it, and gathered some useful bits along the way

Thoughts on F/OSS (9/10): licenses

This is part of a 10 blog posts series on F/OSS thoughts, extracted from a talk that I gave recently.

That's a topic that I love, since it is so controversial.

The AGPL and GPL licenses are evil. They are way too constraining. However lots of anxious people still use them for pretty much anything they write down, fearing that some evil corporation will make some huge money on top of their work.

A common misconception is that the GPL protects from others making money on top of your work which is stupid, as I can sell services and even copies of your work yet still respect the GPL. The GPL has no provision for money matters, like any other F/OSS license.

BTW why do you need to put under the GPL the number guessing Perl script game that you wrote one night instead of going out? Why do you need to apply the GPL on every single library that you write?

A growing number of projects have a "no GPL" policy on the usage of third party libraries, especially in the Java world.

That being said, the GPL (and even worse, the AGPL) are your weapons of choice if you opt for a dual-licensing strategy.

Fair and liberal licenses are what I urge you to use. If you want some protection on derivative works, opt for a fair license, otherwise go the liberal way.

IzPack used to be GPL (yes, we all make youth mistakes right?). We later changed to the ultra-permissive Apache License version 2.0. Guess what? This move materialized by more external contributions than when we were GPL-licensed.

The GPL was also a strong source of confusion for our users, with the repeated questions: "Under which license is my installer?" and "Do I have to make GPL the tools I distribute with IzPack?".

Some people asked themselves those questions... but fore sure some did not even bother and did not pick IzPack, simply because of the GPL. Think twice before you choose this license!

Thoughts on F/OSS (8/10): dealing with success

This is part of a 10 blog posts series on F/OSS thoughts, extracted from a talk that I gave recently.

So you've been working like crazy and your opensource project became a success. Congratulations, you now have to deal with success, which is always great for your ego

The problem with success is that while people were indulgent when you had a small project, they now expect lots from you.

I think that one kind of story that happens to lots of opensource project leaders is having people from companies requesting "urgent" support (through mailing-lists, issue trackers or even direct email), "urgent" fixes requests to the code, "urgent" need for a release with patch xyz, and so on.

People only see their very own agenda and forget that yours may actually be different.

The thing for yourself is to accept that you can't scale with the growing expectations and requests that come with success. You need to live with this fact, and get over it.

Some easy tips:

• take some emotional distance with your project,
• other's emergencies are their fault, not yours,
• delegate to fellow developers,
• keep your investment balanced compared to what others give you back (don't do the work they should be doing, like... reading the documentations or understanding that if they really want that feature tomorrow they can dive into the code themselves).

Thoughts on F/OSS (7/10): the hype

This is part of a 10 blog posts series on F/OSS thoughts, extracted from a talk that I gave recently.

We computer freaks are lucky to be living in a field where there is always something new up for grabs: methodologies, libraries, frameworks...

If you manage to create a successful application, you will go through many hype cycles while you maintain it. One day a brand new methodology will arise, and you will be doomed for not using it. The other day a new cool framework is out, and again, shame on your if your project does not have it.

There is so much pressure for staying ahead of the game that you may even find yourself in the position of envisioning a complete rewrite of your codebase, just because it feels so outdated.

Come on, don't do that! While it is an absolute necessity for yourself to continuously learn new methodologies, frameworks and approaches, it does not mean that what you did in the past is fundamentally wrong.

When I started IzPack, I was using Java 1.2. Apache Ant was not existing yet (and thus neither Maven was). Java had no XML libraries. Nobody talked about test-driven development (I think JUnit did not even exist). Dependency injection and aspect-oriented programming were unknown buzzwords. Design patterns were all the rage ( funny how nowadays lots of patterns are considered anti-patterns).

When you look at the IzPack code today, yes it feels old. It does not follow what we now consider best practices. And you know what? It still works well, and it still solves people's problems.

Don't let the hype kill you. Don't feel gulty. Write code with the best practices of today. What's important is not writing code today with the practices that were considered as best 5 years ago.

You can't help the hype making your code look bad. But what the hype can't break is code that actually works