Two Kinds of Open Source

There are two schools of thought about when you should release open-source code. One school says you should release it as early as it has any chance whatsoever of being useful or informative to other people. The other school says that if you can’t commit to doing it right – proper source control, packaging, bug tracker, etc. – then don’t bother. I’ve come to the conclusion that both views are right. The release-early approach is essential to maximizing collaboration, while the do-it-right approach maximizes user-friendliness. One is developer-focused while the other is user-focused, so the key is to be prepared to do both at the right times during the project’s lifetime. In fact, I’ll suggest a very specific point where you should switch.

  • Individuals contributing their own time (or sponsored to do stuff on some other not-for-immediate-profit basis) should use the release-early approach.
  • Companies actually selling stuff for real money (even if a free version is available) should use the do-it-right approach.

To illustrate the reason for this “mode switch” consider the two ways people get this wrong. On the one hand, you have developers who play stuff too close to the vest, who won’t release their code until it’s a perfectly polished gem. This is actually an urge I have to fight myself, even for code that’s only “released” to my own team. I don’t want to put code out there that might make people think I’m stupid or careless, so I keep it to myself until I’m at least sure that it’s sane. The problem with this approach is that it relies too much on the individual programmer’s motivation and ability to make progress. Lose that ability, and what might have been a useful idea sinks without a trace. Getting stuff out early at least makes it possible that someone else will get it over that immediate roadblock so that progress can continue.

The other way to screw it up is to form a company around an idea and still treat it as a throwaway. This is kind of what jwz was complaining about recently, and that’s what inspired this post. Examples are legion of companies that just toss their crap up on github not just with a “hey, this might be interesting” but with “you should be using this instead of that other thing” and then fail to stand behind it in any meaningful way. That’s getting a bit too close to fraud for my tastes. The reason companies get and accept funding is supposed to be (largely) to develop that infrastructure and hire the people to do all the less-fun parts of programming, because that’s the only way to make the company sustainable. If that money is instead spent on buying favorable TechCrunch/GigaOm editorials or sending “social media experts” to every conference everywhere, then both users and investors are being misled. It’s supposed to be a business plan, not a “cash out before the bubble pops” plan.

 

2 Responses

You can follow any responses to this entry through the RSS 2.0 feed.

Both comments and pings are currently closed.

  1. nicu says:

    If the company is selling the stuff for real money, they should also ship the software on schedule (while making it sure is *good*), customers depend on those schedules.

    Anyway, how about the third case, found very often, when the software is created by a community comprised of both individuals on their spare time and companies?

  2. Jeff Darcy says:

    That’s a tough one, nicu. One common solution is to do both, in different contexts. The best known example is probably Fedora vs. RHEL. The upstream/community version can be very bleeding-edge at a possible cost in stability or polish, while the downstream/corporate version can turn that on its head. (In fact Fedora does better than a lot of projects in terms of completeness, so perhaps it’s a bad example.) My hope is that upstream GlusterFS (from gluster.org) and downstream Red Hat Storage can apply this same kind of model, though today I think they’re still too intertwined. It’s kind of extra hard to maintain that separation when practically all of the developers are from a single company.

    In other cases, the answer might just be to pick one model and stick with it. Since it’s hard to get companies to devote resources to “maybe it’ll work someday” projects, this will generally tend toward the more heavyweight do-everything model. Basically, once a company is basing their own products on something they should expect to devote some resources to rounding out the package instead of expecting a ready-to-sell package to come from upstream.