Blog‎ > ‎

Summary from “What's In It for Me? Benefits from Open Sourcing Code” by Brian Fitzpatrick and Ben Collins-Sussman

posted Sep 26, 2011, 12:14 PM by Unknown user   [ updated Dec 15, 2011, 1:10 PM by Victor Reina ]

Vídeo de YouTube

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:

  • “Open source” your code, but don’t use an OSI-approved license. Your open source project is not registered legally. This is a good option for a quick-easy start. You need nothing but your code.

  • Pros:

    • Public relations splash.

    • Effortless.

  • Cons:

    • You’re not open source. This could make some users and developers to ignore you.

    • You’re missing the benefits. There are benefits when you register your project as an open source. While you ignore this, you won’t get any benefit.

    • Open source zealots can destroy your project. Since you don’t have any legal protection, they can do whatever they want.

“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.

  • Pros:

    • Public relations splash.

    • Effortless.

  • Cons:

    • 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:

  • Pros:

    • Public relations splash.

    • Occasional volunteers can send patches.

    • A bit of credit from real techies.

  • Cons:

    • 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:

  • Public discussion, public repository. Committers are mostly employees; occasionally a volunteer is given the keys. One entity (corporation, lead developer) “rules” project and makes all decisions.

  • Pros:

    • Public relations splash.

    • Even more credit from techies.

    • Better quality volunteers: they can participate in discussions, sometimes commit directly.

    • Results in better software.

  • Cons:

    • Is not a long-term, sustainable community.

    • People can get angry if there’s a drastic change of direction.

Consensus-based development approach:

  • Almost everything is public; decisions are based on consensus of the committers. Commit privilege must be earned by everyone.

  • Pros:

    • Continuously increasing public relation benefits.

    • Long-term, sustainable communities.

    • Complete techie credit.

    • High quality volunteers.

    • Trust from other companies and participants.

    • Results in even better software.

  • Cons:

    • Little short-term benefit.

    • In the short-tem, project agenda must come first.

    • Hard work.

    • You need to hire strong leaders.

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:

  • Be very careful about scoping.

    • Too broad: attracts the wrong contributors.

    • Too narrow: attracts no interest at all.

  • Non-goals are important.

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.