Recently I’ve been talking with a co-worker who is working to re-fashion the community standards for a pretty large open source project that is funded almost wholly by the federal government. The project is several years old at this point. While it has a solid user base, it has not been successful in fostering a community of contributors. Up until now the government has contracted out a development team to develop and refine the product.
It was decided (I don’t know at what level) that this project needed to be “more open-sourcey”. The tasks that were came out of this desire were to re-evaluate and modify the internal open source process as well as the public open source strategy. At this point I was totally un-involved with the project and these tasks went into the team’s hopper to be made into sausage.
At the 11th hour, I stumbled on to this issue and the project leader forwarded me the documents that the group had worked out. Now, my personal philosophy (heavily borrowed from others) to build and have a healthy FOSS project is the following:
- Release the project under a known and accepted Open Source license, and do it properly.
- Keep barriers to community contribution as low as practically possible.
- Keep processes within the project as transparent as is practically possible.
Of course each project has it’s own specific issues and needs, but I sincerely think that if a team is solid on those three things, most other things will sort themselves out by a community being a community.
The process that this team had come up with wasn’t particularly close. It involved emails, approvals, in-house SVN branches (yes, they still use SVN), and other methods that are certainly not “low barriers” to a typical contributor. After some discussions with the team members and asking some questions, the process ended up significantly lighter, utilizing the already existing code-review system that has a 4-5 field registration form.
While this ultimately was a success, the part that really amazed me was how this project almost fell into the trap of being “sorta’ open source”. I later found out that a member of the project had already spoken with multiple experts in the arena of building open source communities and somehow their advice had been disregarded.
Within the project there was a desire for the “paid team” to control the core code base, with no real mechanisms for a community to become involved with it. The “community” contributions would essentially be relegated to plug-in type extensions. One thing that has never proven successful in the FOSS world is keeping the community at arms length and still expecting them to be contributors instead of simply consumers.
Open Source is loud and noisy when at its best. In a perfect project, decisions are a practice in theoretical democracy. In my experience, government-funded projects that claim to be FOSS don’t want to try and manage this type of environment. I can’t really blame them, as it’s hard to attribute billable time to a 17-year old in Denmark who fixed a bug simply because it was interesting. There’s a lot more to being an Open Source project than allowing downloads from a version control repository for no fee, and the government projects and contractors I’ve worked with to this point are having a hard time learning that lesson.