I don’t know why Alan Cox is using »Town Council« instead of the good old term »Community«, but his lessons learnt from a project are interesting:
Release code right from the start. It doesn’t matter if its not very useful. The best way to sort a town council is to simply do the job then tell them it has been done. Linux, KDE and GNOME have all taken this attitude and all done well from it. You can argue about the right way to program for a lifetime. Once there is code out there people (whatever their skill) can play with it.
Appreciate there are people who with a bit of help will contribute very much to a project. If their first patches are buggy don’t put them down, explain why there is a problem and suggest solutions or places to look for examples of solutions. Every minute spent answering real questions helping someone work on a project will be paid back ten-fold to the project, and incalculably to society.
Don’t forget non programmers. I find it sad that many people when asked „name the most important five Linux kernel people“ rarely name some of the most important folk of all – the all to forgotten people who maintain web sites, change logs, mailing lists and documentation are as important. Linus says „Show me the code“. That is a narrow view of a real project. When you hear „I’d love to help but I can’t program“, you hear a documenter. When they say „But English is not my first language“ you have a documenter and translator for another language.
Well, his lessons are not that new. Berkeley Professor Steven Weber wrote (more or less) the same in 2004 from a more general perspective:
“Make it interesting and make sure it happens.”
— Combinations of attraction and persuasion point participants toward problems.
“Scratch an itch.”
— Address an immediate problem or opportunity.
“Minimize how many times you have to reinvent the wheel.”
— Freed from worry about “lock-in,” adopt others’ foundation solutions.
“Solve problems through parallel work processes whenever possible.”
— Traditional development process relies upon an engineering archetype, in which an authority decides the path to be followed in development. Open source process follows an evolutionary archetype, in which the community allows multiple parallel paths to generate multiple alternative solutions, from which successful solutions are later selected.
“Leverage the law of large numbers.”
— Open source projects engage many bug-hunters and bug-fixers.
“Document what you do.”
— The larger, dispersed community is more reliant on documentation.
“Release early and release often.”
— The evolutionary model rewards frequent iterations (generations), but puts a strain on those that must select among many submitted solutions.
“Talk a lot.”
— Direct communication within the community, with lots of open conflict, typifies open source processes.
However, Steven Weber was not the first one analyzing free software, there is also … — no, I’ll stop here 😉
We are standing on the shoulders of giants, even when understanding of what free software is about 🙂