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?

Posted: February 28th, 2009 under Development, OpenSource.
Tags: , , , , ,

« Previous post Next post »

Viewing 23 Comments

    • ^
    • v
    Refreshingly honest (and open)! There are very good reasons to go open core with open source, and, ironically, community is probably the biggest reason (see http://news.cnet.com/8301-13505_3-10067267-16.html). The key is to get the balance right and to ensure one always has the chance to be forked: so long as that fundamental right is retained, and community is fostered such that it's a reality (and, hence, a check on the company doing Very Bad Things), open core is the best way to foster both community and company in tandem.
    • ^
    • v
    Since OpenNMS uses a version of the Sun contributor's agreement, you don't lose your copyright when you assign it, so it doesn't restrict anything.

    Also, we do have a little C code (Java can't do ICMP raw sockets), but we avoid it when possible for maintenance sanity. :)

    In the end, I think the biggest issue here is the catch, "with the strong assumption that the product completely stands on its own without those add-ons" -- in the end, Tarus believes, as do I, that it creates an inherent tension between the community and the company that isn't there in a pure services company. The norm in open-core is crippleware (or at least borderline crippleware), not benevolent open-source with a few commercial addons for niche markets.

    I do see your point about the level of commoditization being an important factor, but how do you define when it's worth being a hybrid company rather than just doing open-source, or just doing proprietary software?

    In all things, there will be exceptions, and I'm sure one or two open-core companies will ride that line successfully, but IMHO, the choice between what becomes open-source and what doesn't will always cause friction, and as a model, open-core will fail.
    • ^
    • v
    I agree with your evaluation about Tarus's market. It appears that once a technology goes open-source, and the open-source implementation is good enough, the commercial products are either forced to change their model or they have to over-market their products. In monitoring, there are a bejillion solutions and they're all pretty much the same. Differentiation is style-based, not usually functionality.

    While I definitely don't want to see RL out of business (ever), I think you've got a problem of walking the fine line. Frankly, I generally don't need RL's professional services because the product is serviceable on its own. I try to help with puppet, but between my day jobs and the rest of my life, the learning curve has been pretty steep. So you don't get me for free, and I can't really justify paying you in your current model. Moreover, if you changed your model to where I had to pay you, I would probably be economically forced to move to a different solution. Making crippleware would just cause people (at least people like me) to seek other alternatives, so that seems counter-indicated. And as Matt says, community seems to be the key to success. However, ask Zed how much revenue ubiquity got him....

    So where do you go from there? Is slow growth The Way? Do we just need to spread the word more? I don't know the answer, but I do keep looking for ways to address it.
    • ^
    • v
    Why is it a sin to want to make money from selling software?

    There are very clear reasons why "Open Source" became an independent term from "Free Software", in my opinion. One, was to ensure clarity ("free" being an ambiguous term). Two, was to focus on promoting the business benefits of open software instead of the moral arguments made by the FSF. Many people don't agree with a moral philosophy that equates software (or other IP) freedom with political freedom. They see it more as an economic tradeoff.

    Now, I do think it's somewhat disingenuous to use "open source" as a form of vendor identity politics, to try to glean some "cool factor" out of having an open core. At base, Tarus is right -- if your business model is about making money from selling software, you're not much different from any proprietary company, except:
    - you're more collaborative and open about what the product actually consists of, which helps drive adoption,
    - on the other hand... you've made the questionable decision of diluting your the core of your product's IP rights, thus lowering your valuation in the eyes of investors.

    Now, where I think I disagree is when he claims that "pure open source" is catching up. If the revenue model is services & support, that has similar scalability in revenue and margins as a consulting business - i.e not great. These companies will never be valued (i.e. capitalized) in the way a software company is normally valued.

    A well-funded company can do things much quicker and of a larger scope than a bootstrap or a services-fed company. But that requires a level of financial performance that the "pure open source business model" cannot deliver, with one notable exception to date : if you can build an exclusive brand that you protect under trademark law -- which is RedHat's game over CentOS.

    Copyright assignment is rough, I agree. In a way it's just about simplifying things, in another way it's about eliminating possible competition.

    The business models I think work (I.e. deliver sustainable growth on par with existing software companies) are:

    - Dual license (i.e. paid commercial licenses made available on less restrictive terms than a big copyleft, think MySQL)

    - Blended source (i.e. a mix of closed and open without copyleft, think of how IBM supports Apache)

    - Pure open source with a trademarked brand (i.e. and you threaten people if they ever use your brand in connection with your software and haven't paid a license it)
    • ^
    • v
    Your last point is orthogonal to your others. It's critical for a company that sponsors an open-source project to defend the good name of the project against damage done by improper use of the name. Trademark law (which is distinct from copyright law in the U.S. [IANAL]) is just a tool for enabling that. Look at the PHP programming language -- it's got a bad rap in many security circles chiefly because it's an easy language to pick up, which leads to lots of unseasoned programmers creating eye-wateringly insecure projects written in PHP and then including "PHP" in the names of those projects. It's quite possible to write secure code in a weakly-typed language like PHP that puts ease of use above almost everything else, just as it's possible to write insecure code in a strongly-typed language like Java that has secure compiler and VM design pretty much nailed.

    I especially take issue with the implication (which I could well just be imagining) that lawsuits over improper use of trademarks tend to be lucrative on net. Lawyers are expensive, and I suspect that most infringements of this type end upon receipt of the first cease-and-desist letter.
    • ^
    • v
    I think the answer is "it depends" :)

    Assigning copyright can be a problem in that it precludes many people who work at other commercial companies from contributing code. I have a few friends who are simply unable to contribute work related patches to OSS projects due to the policies of their own company.

    I have no real issue with the open core model. I've seen it work quite well with products like OpenCMS, where a hell of a lot of deployments simply don't need features like LDAP/AD integration, and it has felt reasonable to purchase those licenses in the past for deployments that do need those features.

    On the other hand you do end up with a certain level of tensions over these features between the community and the developers in the parent company in that someone in the community will eventually want to simply reverse engineer the closed source addons as open source, and they'll probably need development questions answered by the developers who are employed by the parent company.

    I've seen this kind of situation put individual developers in a difficult position in the past, as they have both a responsibility to their employer, and a desire to do the right thing by their community.
    • ^
    • v
    It is more of a "it depends" situation. I have no issue with the open core model either.
    • ^
    • v
    Very well said. It is of "it depends" situation.
    • ^
    • v
    I've been trying to write up a rather long comment, but it keeps getting mangled and then not showing up after I edit it. Will do this via trackback instead I suppose...
    • ^
    • v
    While waiting for the trackback to verify, here's my response:

    http://jeffgehlbach.com/?p=62
    • ^
    • v
    Luke - thanks for taking the time to write up your views. I really respect what you and your community have done with Puppet and your viewpoint is important to me.

    I actually took some time off today. I went to a funeral. The woman who died was 90 years old and for the last 14 had suffered from Alzheimer's. During the service I honestly had the thought that if I got Alzheimer's would I wake up every day railing against "open core" software? I certainly hope not.

    Several people have responded to your post much better than I could have, so I'll try to keep my remarks brief. First I'd like to clarify that I do not have a campaign against "any company that produces both open source and closed source software". I don't - I really don't have problems with commercial software and often you'll find me recommending it for certain applications. I just have a problem with commercial software companies that try to market themselves using the term "open source".

    This all started when Matt Aslett of the 451 Group announced the Hyperic IQ product. This is a completely commercial application produced by Hyperic and Jaspersoft. However, he labeled both companies as "open source vendors" which struck me as wrong, especially since no pretense was made at even having a "community version" of the application. It struck me wrong to, in one breath, label these companies "open source vendors" while at the same time announcing pure commercial software.

    Some people seem to think my battle to keep the term "open source" well defined means that I don't understand the difference between "open software" and "free software". Trust me, I do, but in most cases they don't. I am using the OSI "Open Source Definition" which starts out in the Introduction with "Open source doesn't just mean access to the source code". If someone has a better definition I'd love to hear it.

    I really don't know what advice to give concerning Reductive Labs and your decision to, perhaps, provide commercial software. I think it is possible for open and commercial software to live together. For example, I can buy closed source software that runs on Linux. But within a particular application, where does one draw the line? It's really hard.

    See if you can answer this question. Suppose RL came out with a commercial feature for Puppet. Someone in the community comes up with a similar feature and contributes it. How do you handle it? Think of it both in terms of a contribution that is equal to the code you sell, but also a contribution that perhaps isn't very good code but it gets the job done. It seems to me you would be placed in a very difficult position with no real "right" answer.

    Now, I like to run my mouth, but there are several things I keep quiet about. We have come up with several ideas for greatly increasing the scalability of the OpenNMS business while remaining pure open source. We are currently looking for a small level of investment to realize these ideas. However, I'd be happy to share them with you (privately) to see if they would apply to Puppet.

    As for copyright, as others have mentioned we have adopted Sun's contributor agreement which works on the idea of dual copyright. I don't know if it was my work in particular, but when I was introduced to the agreement it had no license notice on the agreement itself. They later added a Creative Commons license, and thus we promptly borrowed it.

    I should also state that I don't have a problem with dual-licenses (a la MySQL) as long as the code remains 100% available under an open license. That could be one way to generate revenue while still being true to the community.

    One last thing: you've helped create something really amazing with Puppet so don't rush into anything. There are investors out there who "get it", so if you are considering commercial software add-ons to Puppet because your VC wants it, think long and hard about it. You'll be glad you took the time, even if you eventually do decide to do it.
    • ^
    • v
    There's way too much in all of these to reply to directly. I think the main things are:

    It's always a tightrope walk, and I'd like to find the path that's best for the product and the community but doesn't so limit our company growth that we can't actually build the other interesting tools we have planned.

    And the problem is the same regardless of VCs: They can be an accelerator, but we have to find a way to continue building our great community while also building an equally great development team.

    It seems like it's a choice between conflict in the wider community (open core) and conflict in the development community (contributor agreements). I've always assumed that the latter is worse, but maybe it's not as clear cut as I always figured.

    Note that I'm operating on the assumption that entirely free software that I can't relicense will keep us from having any meaningful growth.

    We'll be looking at this in much more detail in the next few months, and either way, we'll be making our decisions very public.
    • ^
    • v
    Luke,
    In the open source area innovation is as much about the business model as about the products. IMHO, purist approach is simplistic since it rejects experimentation. I think companies need to consider all options, as you're doing.
    On the contributor agreements, having a core and plugins type architecture seems to ease the conflicts with contributor agreements. In this structure, contributors are only required to sign an agreement if they want to plugin to be distributed with the core product. Contributor can choose not to sign the agreement and users can download the plugins as an add-on. This can create a rich ecosystem around the product that is beneficial for all.

    Good luck with it all.
    • ^
    • v
    Have we seen a truly successful "open core" business yet? (and by "truly successful" I mean by the RedHat, JBoss, MySQL yardstick)

    I don't think we will either because of two market forces that sure seem like they will always work against you:

    1. Your community users (i.e. free users) will resent you because you are holding back the best features (which they likely helped you discover) and new developments (which they may or may not have helped you develop and test). You are also setting up a situation where the most qualified community members (your employees) can't or are strongly incentivized NOT to help the community because your business model wantz to force them into paying. Those are terrible forces for any mature community to bear and would probably kill any nascent community.

    2. Your paying customers will immediately question the value of paying full price for something that they could have gotten 80% of for free. Additionally, you are going to run out of "feature carrots" to force upgrades pretty quickly. For example, lots of organizations would happily stick with Exchange 5.x (if it was free) and just ride out the wave until 7.x was free. And adding to your troubles, you and your competitors are going to be in a "featuring freeing" race to the bottom where you try to one up each other by making more and more free.

    And as a side note...

    Am I the only one that hates the term "open source vendor"? First of all, isn't it a bit of an oxymoron? (you can't sell open source.. if it really is open source) Secondly, it's so ambiguous that it allows any company to attach themselves to the good name of open source and dilute/corrupt the meaning for those who don't really understand it. And third, if Reductive Labs wants to roll out a completely new product line that is 100% closed source and doesn't harm or restrict the Puppet community, why should they be forced to question that business decision because somebody else thinks it goes against a label?
    • ^
    • v
    Hi!

    I've never thought that requiring code contributions is a sin, I've always thought it just meant that you don't really want contributions. A lot of groups will say "community, community, commmunity"... but when it comes to actually encouraging community and doing what is right to grow it, few groups actually follow through.

    Cheers,
    -Brian
    • ^
    • v
    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.
    • ^
    • v
    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.
    • ^
    • v
    i did not think that we can make money in such an easy way
    • ^
    • v
    This was an awesome way to make money that is also open source. Thanks for sharing overall on how to make money.
    • ^
    • v
    That Sounds interesting, I agree with you.Please keep at your good work, I would come back often.*
    • ^
    • v
    who the heck invented ,money??? the world is doomed because of it now!!!



    best identity fraud protection
    • ^
    • v
    Open source is not easy for every peoples and also some people cant able to understand perfectly.
    • ^
    • v
    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.
 

Trackbacks

(Trackback URL)

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus