Pauses Café

Vincent Massol was apparently in a blog mood today, as he already made 2 interesting posts, one on Distributed Builds, one on “Increasing open source project contribution”. Let me answer to the latter.

Vincent, I completely agree with you. Althought there are many things that will help make an open source/free software project successful, lowering your barrier of entry is an critical factor.

Splitting your software in modules is a good step toward that goal. For example, check the mozilla project. While very high profile, it doesn’t have many contributors. This seems to be a problem for them. The barrier of entry is high and the code complex. On the other side, Linux, perhaps with a similar number of users has many more contributors. I believe that by nature, the OS is more modular, and it makes it easy to modifies some parts, in particular the drivers.

But lowering the barrier of entry can also be done by:

• take care of your users. They are potentially the next generation developers. In particular, make problems easy to report and to debug. People curiosity will be much increased that way. At the same time make sure that user questions are answered in the user list.
• use a one step build system. Once again the Mozilla project is a good example. It was very hard to build on some platforms (e.g. Windows) while were those with the primary potential users. Many people were scared away because of that. On the other side, compiling the kernel is a simple as running make. Much easier -> more developers.
• make sure that your build system lowers the time it takes for a change to be tested. If you can avoid rebuilding completely your software for each change, that’s a big plus. There the idea of using modules can be very helpful. Deployment should also be as easy as possible (and not necessary if possible).
• pay attention to external contributions. Review them as fast as you can. Whether you will accept it or not is not that important, but make sure you don’t let . The idea is to empower users into contributors then developers. If you’ve introduced modules, you can grant your developers rights to maintain parts of the system. If they mess around you can always remove those rights afterwards. I see that you apply this idea in Cargo and it seems very effective.
• add unit tests. Although not easily applicable to all projects (e.g. when you work with a particular complex hardware), by providing unit tests you enable cooperative development. People are not afraid of changing stuff as they have a harness. Using a Test Driven Development helps further as people focus on what they want to do.
• strong and consistent leadership. Accepting too many contributions can be fatal for an FOSS project. Brookes talked about conceptual integrity 30 years ago. He was right. Not so long ago, an Apache project became “Everything but the kitchen sink” and dissolved. So, to refuse contributions is not a bad thing, it’s critical.
• and for the developers, keep your system stable. Use Continuous Integration and run your tests when you build. With regard to FOSS, it could be interesting for the project that have a continuous integration system that automatically merges and tests external contributions during special builds. In fact it looks like a good idea and I will look into it a little bit as it could be a way to provide Continuous Integration to non actual developers, lowering their barrier of entry. People would only have to queue patches or group of patches for them to be automatically tested.