Ben Collins-Sussman & Brian W. Fitzpatrick are two of the original developers on the Subversion project. They worked for CollabNet, the primary sponsor of the open-source project Subversion. They gave a session on the pros and cons of Open Sourcing a company’s code, listing all of the various ways to do it.
The first question a company might ask is why go open source? There are a number of reasons as to why it makes sense to open source your company’s project:
- Improve the quality of the software.
- Create a more meaningful relationship with your users.
- Public Relations benefits:
– Goodwill from techies. Most developers have a very positive attitude to open source projects and companies that support them.
– Free-and usually talented-labour. If you can attract developers to work on your open-source code, they are likely people who are very motivated (they’re doing it in their spare time) and talented (bad programmers don’t tend to program on their own time). Not too mention, the work is done for free.
– You can influence the direction of your specific industry by leveraging other developers.
Creating a successful open-source project is not easy. The following are some of the key indicator’s of the health of your project:
- Lots of usage. If you don’t have a community, than it’s usually a dead project.
- A number of active developers.
- Constant improvements and releases.
Collins-Sussman and Fitzpatrick then laid out 4-5 different types of Open-Source projects. Each type of project is an option for your company, but from the perspective of a techie, this list goes from worst to best.
1. The Fake Source Approach: Open source your code but don’t use an OSI approved license
- Public Relations Splash
- Misses the benefits of an open-source project because it’s not really an open-source. It isn’t likely to gain any credibility from techies.
2. Throw your code over the wall approach: Post a tarball and then walk away
- Public Relations Splash
- No community. No cred from techies.
3. Develop internally, post externally: In house development with a public repository
- Public Relations.
- You will probably receive occasional patches from developers.
- A bit of cred from techies.
- Your community is mostly internal to the company.
- The external community (if it develops ) is likely to form elsewhere
- Attracts follower developers, not innovators. Many developers will have some distrust of your aims because only they will assume that you only care about the corporate agenda.
4. Open Monarchy: Public discussion and a public repository.Committers are mostly employees, but there are some exceptions.
- Public Relations
- Much more cred from techies
- Better quality volunteer resulting in better software
- Not as sustainable in the long-term.
- Risk of angry revolutions. People can fork the project.
- General distrust because you only care about corporate agenda
5. Consensus Based Development: Almost everything is public and decisions are based on the consensus of the comitters. Commit privilege must be earned by everyone.
The project exists independently of the corporation. This is usually very hard for corporations to embrace because they fear a loss of control.
- Continually increasing pr benefits…. but no big splash.
- Best chance of building a long-term sustainable community.
- Complete techie cred and trust from other companies and participants.
- High quality volunteers. This results in even better software and reduces the hit-by-bus factor on the project. The project can also become a great pool of potential hires for your Human Resource department.
- Helps prevent burnout on your team because your have contributions and ideas from outside developers.
- Little short-term benefit, because in the short-term the project agenda must come first.
- It’s hard work.
- You need to hire strong leaders (not average developers). It’s really important that you get the right core culture on the project.
Collins-Sussman and Fitpatrick were advocating for a Consensus Based Development project because they feel it will yield the best results over time. And they went into some of the common objections that people have toward embracing this type of open-source.These include:
Objection: Strangers will force me to do things, or nasty people will hack my project!
Answer: Craft your community well by:
- Choosing a well scoped mission
- Have your developers promote a strong respectful culture.
- Set the discussion tone carefully
Objection: What if someone forks the project?
Answer: This is extremely rare in a consensus-based development:
- People (especially developers) prefer to work together and tend to get better results by being part of the community.
- Consensus based development allows the majority to move in one direction. It’s really hard for a hive to swarm w/out at least 50% of the bees.
How to build a consensus based community?
1. Come up with a goal that is:
- Something useful
- Something people can get excited about
- May only benefit your company in the short-term
2. Write a mission statement:
- Be careful about scoping. Too broad and you attract the wrong contributors. Too narrow and you attract no interest at all.
3. Prepare your team:
- Read Karl Fogel’s book about producing open source software.
- Learn how to set the community tone.
- Decide on a process for admitting new committers.
- Learn how to diffuse poisonous people.
- Thicken everyone’s skin.
4. Move all development to public:
- Launch public mailing lists, repository, but tracker.
- Minimize use of internal mailing lists.
- Do some PR to attract volunteers.
- Start a mailing list if possible.
Choose the best strategy based on your goals, because there are always trade offs. In the majority of cases, consensus-based projects create the best software
and yield the best results in the long-term.