Yesterday, I added Wolfgang Kechel as a committer to the Hecl project, because of the good work he’s been doing on it. He’s demonstrated consistency and quality over a number of months, and has also shows he understands where I want to go with the language, so it was a natural thing to do.

Adding a new committer is not always so clear cut, though, and it’s sometimes a difficult decision, especially with smaller projects. I find that it’s much more fun to work on projects with other people, so I want to encourage them to get involved, and granting access is something that ought to give people a bigger stake in the project, and reward/encourage them in their efforts. In practice, it doesn’t always work out that way, though. Often, after a bit of initial work, they dissappear, which means they weren’t really that interested in the first place, and you shouldn’t have bothered granting them access to the code – they could get by just fine by submitting patches.

The question of openness vs control also plays a strong part in the difficulty of the decision. I think the Apache Software Foundation way of doing things (decisions by consensus of those who work on the code) is pretty successful for well established projects, but I’m also convinced that the “benevolent dictator” model is best in some cases. Design by committee doesn’t work very well for projects like a programming language where you really want to have one coherent vision, rather than some sort of frankenstein mishmash of pieces. (As an aside, Larry Wall, has done a fine job of proving that you can have – even revel in – a mishmash, even with a ‘dictator’!).

The point being that it’s a little scary to hand someone the keys to your project, because you take a risk on them working counter to your goals, especially in new projects without a self-propagating culture in place. An established language like Python has a fairly large number of people who can instinctively tell you if a new feature is “pythonic” or not. But for a small, new project like Hecl, the risk is that there is more room for unproductive arguments, or having to back out “bad” changes should someone really take off in a direction you don’t like. Of course, with Hecl, I think it is at a great point in its life. There is a lot of room to hack, because it isn’t used by many people, so we don’t have to worry about angry users if we break it while trying to improve it!

All things considered, it’s a positive step to get more people involved, but it’s important to start building a culture in order to keep your code going in a healthy direction. Depending on the project, that culture might include a healthy dose of what is and what isn’t within the project’s scope, or it might simply regard the quality of code considered acceptable. For instance, Tcl’s standard library is pretty open to whatever people want to implement, however you must accompany your code by either tests or documentation, and preferably both.

I think the most interesting phase is when you are “bootstrapping” – going from just one person to a group. Judging by the number of small projects that have fallen by the wayside without ever getting more than one person to work on them, it’s also the most difficult period in a project’s life.

What do other people think? What tactics do you use to get people involved, yet still make sure they are the right people?