Increasing open source project contributions
[ vmassol ] 11:21, Friday, 11 March 2005

I may be dense but I've just realized today that there is a potentially simple way to increase participation to an open source project. That's always been one of the questions on my mind: how do I make my open source projects more successful? For me a successful open source project is one which has a rich developer community. How do I make this possible? There are of course several ideas to make this happen but the one that dawned on me this morning is that the project has to reduce its complexity (by making it more modular for example).

Indeed, the barrier to participation is often due to the fact that a user who wants to participate will need to understand the whole design, how the different classes are entangled, what effect a change here will have on the rest of the project, etc. Thus, if we make the project more modular a contributor who wants to participate will only need to understand the design of a given 'module'.

A 'module' would need to have some good-to-have characteristics:

  • Very loose coupling with other modules
  • Clearly defined and *published* interfaces. There should be some documentation on the project's web site explaining them and a tutorial showing how to implement new modules (or swapping a module implementation by another one) for example.
  • Separate builds so that it's easy to build only the module (this can be alleviated if the master build is easy to use (i.e. no property tweaking necessary, it just builds - As it's the case with good Maven builds... ;-))
  • Separate documentation on the web site, so that the website itself is modular and the complexity of each module is hidden in that module's web site. Thus the top level web site would be quite simple only listing what the project does as a whole and listing the different modules

Interestingly one way to implement the 'very loose coupling with other modules' characteristic is by using a Service Architecture. This can be done for example by using the Dependency Injection pattern and/or using a lightweight container - PicoContainer, Spring, etc).

This is probably obvious stuff but I've just realized that it's not only good design practices but that it'll also help open source projects attract more contributions. Of course that leads to another topic which is when to accept contributions and how to maintain them in the long run but that would be another discussion...


Comments

Vincent, I started to answer to your post, but my answer was becoming too big. So I put it on my blog.

http://www.coffeebreaks.org/blogs/?p=4

--jerome, March 11, 2005 02:00 PM

Wouldn't it be great to refactor Maven so that it uses Spring at its core and Groovy as a scripting language?

A plugin could then be developed in pure Java. Its configuration defined in a Spring bean factory with a propertyconfigurer for properties files which may override default values. Each plugin provides its own bean definition that gets registered in a Maven Spring application context.

--Thomas Van de Velde, March 11, 2005 02:02 PM

Hi Thomas,

This is what is happening with Maven2. It's being built around a lightweight container (called Plexus). It is indeed the goal that plugins are developed in Java or in other languages.

--Vincent Massol, March 11, 2005 02:11 PM

This strikes me as very similar to what the Eclipse project does. Aren't plugin's just really loosely coupled modules. Look how many people indirectly contribute to Eclipse by writing plugins and don't even think of it as contributing to the project in the same sense you would if you were contributing to apache.

--Brian, March 11, 2005 02:31 PM

Out of curiosity: Why not Spring? Spring is now well know and documented, which is btw another key element that makes OS projects successful. Is there anything that Plexus will provide that does not already exist in Spring?

--Thomas Van de Velde, March 11, 2005 03:51 PM

If the Maven community wants to be taken seriously you guys really need to stop making bone-headed decisions like this. Plexus? Who the hell is using that? Just because it's someone's pet project is no reason to base an already questionable project on it. When you're trying to sway public opinion (much of which has been negative toward Maven so far) you have to go out of your way to be mainstream and make it easy for people to use. This is why Venture Capitalists won't let startup companies base their business off of a dependency on another startup company. Maybe Plexus offers something that Spring doesn't (I doubt it), but is it really worth the risk of Plexus dying or just of people like me and Hani pointing and laughing at the silly decisions?

--Jason Carreira, March 11, 2005 09:24 PM

While reducing complexity is great, I am not sure that having a great amount of different Maven subprojects is necessarily the way to do it. A clean package structure can go pretty far...
By having many different Maven subprojects within a main project the newbie developer has to first figure out in which package tree to look for stuff and once he's knows that, he still has to look at the right package/classes. So there is one more step involved in figuring out where to look. In essence this actually adds complexity on the initial usage level. As a newbie I have to learn a whole lot more before I can start (i.e. how the project is modularized).
The critical question is probably "how big is the project?". It would be interesting to try to define a certain number of classes that require a new subproject. And also a minimum number of classes to justify a new subproject.
Anyway - I believe the key to helping others to contribute is to provide them with an efficient way to find what they need. This must be a clean and understandable structure and should be availability through IRC, mailing list etc. FAQ's or Howtos.

--Hendrik Schreiber, March 17, 2005 10:59 PM
Post a comment









Remember personal info?