Why go open source? What advantages can we get from an open source project?
Some sort of net gain. You create a bigger project, connected and known all over the world.
Create better software. The more people who contribute to the project, the better software you will get. United we stand.
Create a real relationship with your users.
Measuring “health” of Open Source. We need some characteristics to own a healthy group:
Lots of usage (not users). You need your project to be well known even before its release.
A number of active developers. This is clearly the most important characteristic to go ahead.
Constant improvements and releases. Your developers need to see a constant advance.
Remember: no community = dead software.
There are some approaches to have an open source project, with their own pros and cons.
“Fake open source” approach:
“Throw code over wall” approach:
Post tarball of the code, and then walk away. You just start a project, write some code, upload it to the internet and wait for someone to bring you some help.
Public relations splash.
No community to keep software alive. Since you don’t have any robust team nor plan, you won’t cause a big impact.
Real techies give little credit. Technology experts know what you did and how much effort you put there, and they limit their credit.
Develop internally, post externally approach. You make your code inside your company with your people, and then you upload patches and solve bugs externally. In-house development, public repository:
Community & momentum is wholly internal.
External community likely to form elsewhere.
Attracts only “follower” developers. You won’t get too much full-time developers. Instead, you will get occasional developers and people who follows your project.
Open monarchy approach:
Consensus-based development approach:
Consensus-based is probably the best approach, because traditionally companies isolate developers from users. With this approach, users will keep in touch with developers, resulting in a nice relationship. In the end, the software is better. You could have some bad feelings about this approach, like “Strangers will force me to do things!” or “Nasty people will hijack the project!” You need some basis to craft your community:
Choose a well-scoped mission. If developers like your mission, then they will help you fully-focused.
Have your developers establish a strong, respectful culture. A respectful, nice community is a strong community.
Set the discussion tone carefully. Try to be the pacific one.
Have a well-defined process for making decisions.
So, how do you build the consensus-based development project?
First, come up with a goal:
Something useful. Clever ideas are gold.
Something people can be excited about.
Might only benefit your company indirectly, or in the long-term.
Second, write a mission statement:
Third, prepare your team:
Learn how to set community tone.
Decide on process for admitting new committers.
Learn how to diffuse poisonous people.
Fourth and last, move all development to public:
Launch public mailing lists, repository, bug tracker.
Start with one mailing list if possible, split later.