Links:

Categories

Recent Posts

Bookmarks

Recent Status

Upcoming Events

I'm speaking at Open Source World in San Francisco, August 12-13 I'm speaking at The Ruby Hoedown in Nashville, TN, August 28-29

Site search

Categories

February 2009
M T W T F S S
« Dec   Mar »
 1
2345678
9101112131415
16171819202122
232425262728  

Tags

Blogroll

Navbar

Related

The Most Free(tm) Way to Make Money from Open Source

Tarus Balog is on a one-man campaign against open-core licensing, or really, any company that produces both open source and closed source software:

Of course, in the open core model there must be “commercially-available extensions” in order to get companies to sign a “commercial license”. Why is this? Because the open core product has been intentionally hobbled to force companies to buy the closed software product in order to get it to do the things that customers need it to do, and thus to generate revenue for the software company.

I find this article interesting, because he seems to have taken the opposite tack from me in terms of deciding what causes the most dilution of an open source product.

I’ve always figured that requiring copyright attribution is a greater sin than providing commercial add-ons, with the strong assumption that the product completely stands on its own without those add-ons.

As far as I see it, requiring copyright attribution restricts the developer community, while providing commercial add-ons doesn’t restrict anyone anywhere, it just says that some of my code isn’t free.

Sure, I can see if I produce a crippled, useless free product that *requires* the commercial add-ons that it’d be evil, but if the OSS portions actually do kick ass on their own, then what’s the issue?

To me, community is the big differentiator.  If a given OSS project doesn’t actually care enough about a community, then open core is basically a sales tool.  But if it *really* cares about community, then open core always has to worry that the community can thrive without the commercial portions.  I basically think of this as requiring that the open core company always open source anything that’s required by the project or that’s essentially commoditized, but it leaves plenty of room for using a commercial license on those projects that not everyone needs, and especially on those areas that are clearly not commoditized and not many people need.

I think Tarus has a special perspective on OSS success because he’s in what amounts to an entirely commoditized space – there are so many monitoring tools with such a similar feature set that it’s crazy to think anyone would choose anything but an entirely open source solution.  In less commoditized spaces, it likely doesn’t make quite as much sense to stick to entirely open licenses.

This bit in particular sticks out:

If you like your users why not provide all of the features as open source? Red Hat does it, JBoss does it, OpenNMS does it. The answer will always be that their business model can’t survive unless they sell closed source software. In that aspect, I can see little difference between open core companies and Microsoft.

Well, I can tell you that the reason that Reductive Labs is considering producing commercial software is that we can’t afford to produce much more software unless someone pays for the development, and at this point, we have a thriving, healthy community that largely gets huge benefit from Puppet without ever needing help from us.  So, our options are to grow so slowly that all of the interesting opportunities pass us by, or to start producing software that allows us to, at the least, recoup our development costs.

I agree with Tarus’s basic sentiment: A lot of these open core companies aren’t actually producing open source software that you could reasonably use on its own.  But that doesn’t invalidate the model, in my opinion.

His model of providing supported binaries, as Red Hat and others do, only works for those who use compiled languages, which means it’s right out for us.  Maybe we should stick some C in there, just to make it easier to charge for support?

So what do you think:  Is it a greater sin to only accept patches to your product if the contributor is willing to assign copyright to your commercial company, or to produce some closed-source code?

Viewing 76 Comments

 

Trackbacks

(Trackback URL)

close Reblog this comment
blog comments powered by Disqus