Motivation and common ground

I’m interested in what makes a group of independent, smart people work on a project together; and what makes such a project fizzle out or take-off. Open source projects are of the type where people are generally not being coerced into contribution by the firm hand of hard cash; and yet, there are many thriving open source projects around the world. I’m clearly being a bit software developer-focussed here, but examples of people working on projects together without an authority directing them are common in the form of volunteer groups, business startups and hobbyists.

The question of what fuels someone’s motivation to get into a project seems slightly different from what fuels their continued commitment to a project. This is illustrated by the number of times a pub conversation leads to a bunch of people having the intention to do some cool stuff, which then dissipates a day or two later with nothing really achieved.

Yes, wifi-enhanced nipple tassles are exactly what the world needs!

I suggest that the principle reason someone contributes to a project (when they have a choice about it) is because they feel that they are getting something from it that is useful to them for a reason outside of the project. In the ordinary course of things, it is normal to have wants that are individual to you – something that you see as helping you get what you want is going to be worth your while spending time on it.

That point leads me on to the suggestion that the principle difference between a group project that is vibrant and active, and one that dies, is that the people involved all extract some benefit from it. That is to say, the project is a common ground for the people involved in it. Returning to the case of open source projects, this could mean that someone sees the continued improvement of an aspect of a project as helpful to a contract they are working on, or a product they are trying to create. 

As (admittedly anecdotal) evidence of this as a principle, we might look at two things: first, the preference to get involved in niche projects; second, the forking of open source projects.

At the time of checking, the number of projects on (a popular host of open source projects) is 173065. The vast majority of these are unheard-of, small projects, suggesting that they serve the needs of a minority. But that’s the point – people have quite individual needs and will create their own projects when this serves them best.

It is clear that a big project such as the Linux operating system or the Firefox web browser have a large number of people contributing to the project, but it looks unlikely that the contributions from people outside the paid core team are continuing and general-purpose. Instead, they are more likely to be contributions that change things so that the software is useful for that specific contributor.

This last point leads on to the question of forking open source projects. It’s in a developer’s nature to make customisations to software so that it serves their needs or the needs of their clients/customers as well as possible. Projects that recognise this build their cores so that they can support big or small customisations without the need for someone to maintain their own version of the core (this would be a fork). This often manifests itself as a plugin framework for the project (Firefox Add-ons, jQuery plugins).

To use an example close to my heart, I cite Jeremy Ruston’s early development of a plugin mechanism in the TiddlyWiki project:

The above may cast some light onto why wifi-enabled nipple tassels might be one of those pub conversations that, rightly, burns out rather quickly – much like a faulty wifi-enabled nipple tassel might.


One Trackback/Pingback

  1. […] who are implementing these custom features. The more interesting, general, point here is about open-source and plugins. TiddlyWeb’s plugin mechanism lets us deliver a generic solution for TiddlyDocs rooms, which […]