Source code is an inanimate object.

Via Miguel de Icaza, I came across this summary of Google's Summer of Code Mozilla projects. Miguel posted a similar summary for the Mono projects. I encourage you to take a couple minutes and read through the summaries.

Notice a difference between the summaries? No, I'm not referring to the fact that the Mozilla summary is mostly crestfallen while the Mono summary is general upbeat. Instead, notice how much Miguel talks about the people behind the projects where the Mozilla summary only mentions the people in abstract.

I'm not saying that Miguel's focus on people is why the Mono projects were more successful than the Mozilla projects. I contrast the two summaries because they provide the perfect backdrop for a fundamental truth I believe about Open Source projects.

Source code is just an inanimate object. Community is what really makes it all work.

I bring this up now because I've had several people tell me that they have some source code that is "really cool". It does something that some people would probably find interesting. So, they were asking me if I thought it was a good idea to release the source code as "Open Source".

Invariably, I'd smile and say, "It depends."

It depends on what your goals are. If you want to release source code as the seed for getting a group of people to collaborate together then I say, "Go for it!" For example, I pushed for the WiX toolset to be released as an Open Source project because I wanted to build a community around solving software installation problems. Today the WiX toolset improves because there are thousands of people that use it, praise it, curse it, write about it, and some add more code to it. At the same time we make new friends, learn new things (about software installation and other happenings in the world) while, generally, having a good time.

On the other hand, if you just want to drop the source code where people can download it and walk away then I would ask, "Why bother?" Dropping off source code like this is no different than providing some sample code in an MSDN article. People may look at the code and admire its beauty but it certainly does not create a living "Open Source" project.

Of course, someone else may come along, download the source code and create a community without you. If this is your goal then I would encourage you to instead focus on finding a community leader for your source code. Without a community leader, your source code is likely to go as far as the Summer of Code Mozilla projects... nowhere.

Comments (5)

  1. Chris DiBona says:

    Great post, but I take one exception. You say "Why Bother" with open source licensing, when one could drop it into a MSDN article. I applaud your intent, but I’d rather see examples provided in msdn and on other technology websites and books explitly licensed under an open source license, as many are simply not appropriately licensed for direct use.

    But really a good post.

    Chris DiBona

  2. Chris, that’s a very good point.  For sample code released anywhere, I would hope the author would license it liberally.  Preferably sample code licenses would lean more towards public domain or permissive than reciprocal or even more restrictive.  But having written an MSDN article, I know that licensing the sample code was the last thing I was thinking about while writing/editing to a deadline.  <smile/>

    Now that I think about it, maybe "Pick a license for sample code" would be a good thing to explicitly call out in MSDN approval process.  I’ll float that idea around.  Thanks, Chris!

  3. Great post Rob, I had actually read both posts already but hadn’t twigged to the explanation for the difference.

  4. saudhall says:

    Nice one, i was just watching your video along with ur wix team, it was cool, i guess there is a lot to learn from you, i think i need to subscribe ur rss feed… urs is a very informative blog…


  5. rektide says:

    mistitle.  you are not talking about source code.

    dotnet source code is dead, even with active communities.  look at something like lisp, or smalltalk, now that is living code.  self modifying code is code that is alive, nothing else is.  code-dom is 1/10 the way there.  dynamicmethod is 4/10 the way there, but its still only half way.  sorry, but being able to only unload an entire appdomain is a joke.  thats not alive code.  there’s so much missing from the clr and clr languages that needs to be there to make our source code truly alive.

    addressing the actual relevant question though, perhaps creating more involved environments will help promote a more lively developer environment.  the life status of the source code is generally orthogonal to life status of the community, but by creating better running environments, we can start creating positive relationships between both.

Skip to main content