Log in

No account? Create an account
Previous Entry Share Next Entry
Managing an open source project? And want more contributors? And better contributors?
Looking at Exherbo we're very successful at getting people to contribute serious amounts of work towards the project. This didn't happen by mistake but rather by carefully considering what drives people towards contributing to open source projects and exploiting the knowledge gained from that.

Did I just say "exploit"? Yes, I did and I'm quite focused on "manipulating" users towards being useful contributors. I consider this manipulation entirely positive as it's just as helpful for the users as it is for the project.

So how do I do it? The first thing you have to realise is that most users aren't going to contribute just because you'd like them to. So you need to motivate people and you need to do so without it requiring too many of your own resources (resources being mostly time in the world of open source projects). Fortunately this turns out to be quite easy when you understand how developers grow from being somewhat insecure and inexperienced towards more proficient developers and (possibly) attain guru status.

You can compare this process to climbing a ladder and just like most other aspects of life this is more like a social ladder than a technical ladder. To gain guru status you first need to gain the respect of other developers surrounding you and the same is true when you're just starting out as an open source developer. Technical knowledge is definitely important but it's just as important that you gain the respect of your peers - without that respect they won't trust you to solve complicated problems and they won't involve you in important decisions.

What I do in Exherbo is that I make sure people can gain that respect as easy as possible without it affecting the project negatively. And I make sure to help people at the lower steps of the ladder in particular since it gets easier and easier to climb the ladder the further you go. Being an "outsider" with little to no respect among your peers (as would be the situation when approaching a new project) makes it much harder to gain any respect than if you've already shown you're capable of solving complex and/or interesting problems.

So how do I help people gain that first bit of respect? First of all I make sure not to solve the easy problems unless it's important that they're solved quickly. It's quite important that there's some easy problems that new people can cut their teeth on. Secondly I make sure that contributions from new people get extra attention - I want to make sure that they get immediate feedback and that their contributions are added to our git repositories as quickly as possible. And thirdly I make sure that their contribution is advertised among all the other developers and contributors. This way the new contributor gains a little respect more or less instantly and feeling slightly more secure should be able to take on larger tasks - it might take a good while before (s)he takes on any task that I'd consider non-trivial but we should be moving in the right direction and everybody should be enjoying the ride.

All this results in several positive things. We get a lot of contributors which was the original goal and the contributors improve all the time. Another really important factor is that developers and contributors that are already quite proficient can spend more time working on complex and more challenging problems. And contributors regularly tell me that Exherbo is the most fun project they've ever worked - I like to think that's because I keep challenging them ever so slightly and make sure they become better developers.

Summed up very briefly:
- Whatever you do, don't fix simple problems if they can wait
- Make sure that (especially) new contributors get as much credit as possible,
  even if you did half the work or more
- Keep in mind that the hidden goal is to help each new developer/contributor
  climb the social ladder in your peer group

And my final advice is to not be afraid of being an asshole. If a possible contributor is clearly unable to understand even the most basic directions and he's starting to drain a lot of project resources you should just kick him out. Otherwise he's going to keep draining resources and the most resources will be taken from new contributors that should focus on improving their own knowledge and skills rather than trying to help lost people. Kicking out such people (you can be civil about it of course) as early as possible might just save several other new contributors. I find it quite important to weigh the cost of possible contributors and focus on getting the most bang for the buck so to speak.

If you follow all this when managing your own project you should start seeing somewhat experienced contributors help new contributors climb the ever so important first steps on the ladder. They might not know they're doing this but you've created a community where this is the natural way of working and as long as you make sure the process doesn't stray too much experienced contributors are going to help keep the process running for you.

  • 1

nice sum up

Cool. I'm conciously exercising very similar practises in my project (uzbl.org) and I agree on many things, especially the giving credit part and always leaving some small tasks open.
You summed it up nicely.


Awesome - I don't really know of anybody else doing this so I'm very happy to know that I'm not alone in thinking this is a good way at managing these aspects.

I'll have to follow your project now and see if I can gain any additional insights :)

Contributors vs. end users

First, thanks for elucidating the mysterious forces shaping and driving Exherbo development. This makes a lot of sense given the nature of the "product", and it works quite well in practice so far. I'm interested in seeing how well it will scale when the number of active contributors passes certain thresholds, e.g. Dunbar's number (~200).

One of the "About" items on Exherbo's website states, "For distribution developers, not end users." In light of the process you described here, I suggest replacing that item with "For distribution developers and contributors, not end users." which makes a sharp distinction between "users" who actively work to improve Exherbo and the typical "end user".

Re: Contributors vs. end users

I'm fairly sure that this process scales to big sizes. One of the obvious problems in big projects (big meaning many project members, not neccessarily reflected in lines of code or similar) is that very few people are doing any mentoring at all and most of the mentors are fairly bad at it. The process I've established makes sure that just about everybody grows into the mentor role and that everybody keeps learning from the process - be they "mentors" or "new contributors".

I'm well aware that not everybody is going to take on these roles of course but we've managed to have a large percentage of our users do so and I believe everybody sees the contributor role as something to strive towards.

As for changing the "For distribution developers, not end users" I think you're right as far that it needs changing somewhat. I'd rather go in a different direction however as I'm trying to wash out the difference between developer, contributor and user as much as possible.

In Exherbo the developer title means three things basically:
- Being able to push to the official repositories
- Having an @exherbo.org email account (which really doesn't matter at all)
- Having an account on dev.exherbo.org that you can run irssi from etc. (again, this doesn't really matter)

Being able to push to the official repositories is important of course but most contributors gets their patches pushed in less than 30 minutes (I'd say much less but I haven't done any statistics on it). And more relevant to the discussion at hand, titles such as developer and contributor doesn't say anything about the quality or frequency of patches.

I'm obviously aware of the irony that I'm using those titles myself and thereby pushing the distinction but I'm slowing moving away from that and trying to convince others that there isn't much difference at all.

  • 1