Open Source Myths

In a couple of weeks, at BlackBerry DevCon Americas 2011, I will be giving a talk on “Open Source Code: Understanding the Options and Implications”.  I’m planning to cover the basic components of Open Source projects: License, Copyright, and Governance (and Trademarks – let’s not forget trademarks!), and I will use a few open source projects as examples of how all these pieces work together.  One of the motivations for the talk is RIM’s increased presence in the Open Source community, so I will also briefly cover that.

Time permitting, I want to include some “Open Source Myths”: misconceptions about that must, can or cannot be done in Open Source.

Here is an initial list, to give you an idea of what I have in mind:

  • Open Sourcing means you have to let anybody commit code into your code base
  • If I use open source, I have to open source all my code.
  • If I use a GPL license, I can’t charge any money for my apps.
  • I can limit who can use my open source code by “hiding” the code
  • Trademarks and Brands don’t matter in Open Source
  • ASL2 is much more cumbersome to satisfy than BSD
  • I can save a lot of Development $$s by Open Sourcing my project

If you have your favorite myth, add it to this blog as a comment. The DevCon audience is not very familiar with Open Source, so, don’t be shy, even simple myths can be very useful to the audience.

And, if interested in my session, it is DEV34 – Wed, October 19th. 10:15 AM – Yerba Buena Ballroom 1-2, in the San Francisco Marriott Marquis (nice photo, btw, it’s the hotel from the reflective pool/waterfall in the MLK at Yerba Buena Garden’s)

5 thoughts on “Open Source Myths

  1. Here are some more:
    – once open sourced, the project will just manage it by itself
    – open sourcing really doesn’t take any effort at all
    – open source is less secure than closed source because every hacker can study the source.

  2. I use open source completely aware of its shortcomings and contradictions as the alternative is simply too bleak. Expensive proprietary solutions that require constant updating, and risk being taken over or shelved. Expensive and poor quality developers. And an inability to get under the covers and find/fix an issue where the problem resides in a binary library.

Leave a comment