1. “Best way to serve open source is to make a ton of money on it.” @ 2:09min.
2. “Open source is not a business model.” @ 6:13min.
3. “Open source is a production and a distribution model.” @ 6:29min.
4. “Open source is built on [...] people serving their own needs [...]” @ 9:24min.
5. “[...] the engineering cost [...] is as high as for closed source companies [...] but you get much higher quality software much sooner.” @ 10:39min.
6. “Marketing costs are significantly lower and go-to-market is significantly faster.” @ 11:20min.
7. “Sales: there isn’t much of a difference.” @ 11:35min.
8. “Some people spend time to save money, some spend money to save time.” @ 16:48min.
9. “You get no benefit from open source if there is no community around it.” @ 20:20min.
10. “How much [code] contributions do you get? [...] that's irrelevant." @ 20:40min.
11. "The biggest competitor to us was our own open source version." @ 30:40min.
12. "[Open source companies ...] have massive amounts of intellectual property, not just in the code they have." @ 39:06min.

While Marten touches on "civic benefits" at times, this talk is mostly a condensed review of commercial open source and a good reference from one of its foremost practitioners.

Reference: Dirk Riehle. “The Economic Case for Open Source Foundations.” IEEE Computer, vol. 43, no. 1 (January 2010). Page 86-90.

Available as HTML or as a PDF file.

• The Open Source Research group posted a year-end summary for its first months
• There is initial sponsorship by Red Hat and Novell, demonstrating industry interest
• There was a fair amount of press around the professorship, showing general public interest

All in all, a good end to a year that most of us would prefer to forget. But as Matt Asay is suggesting, this may have been the year that Open Source made it big, so this is something to celebrate!

Stay tuned for upcoming research work on open source, using this blog’s RSS feed, or the OSR group’s home page and RSS feed, and of course the @dirkriehle and @osrgroup Twitter streams!

And of course a happy, healthy, and prosperous 2010 to everyone!

I don’t think that this is a fair critique. SAP has always provided the source code of its main business applications suite to user-customers as part of a commercial license, and users have always customized SAP’s business suite to their heart’s content. In fact, it is the only way to make it work for their needs.

Contrast this with commercial open source firms using the open core model, the emerging dominant business model in this space. Here, the core of the software is open source and free, but if you want to use it professionally, you will almost certainly need to pay for a commercial license, which will give you the missing bits and pieces that make the software usable in an enterprise context in the first place. These missing pieces are not open source and are not provided to the community for free. This works, because hobbyists or low-end users typically don’t need these features.

So what’s the difference between SAP and software firms utilizing an open core business model? It is not the lock-in. Once you start modifying closed source software, whether it comes from SAP or an open source firm as part of their commercial offering, you get, well, locked-in. Migration pains will depend on the extent of your modifications, but not on whether it is SAP or some other company.

The only fair critique is to compare SAP with commercial offerings that don’t hold anything back. But firms with those offerings (like most other) have still to demonstrate viability on the level of an SAP. I don’t expect to see this anytime soon.

Disclosure: I used to work for SAP in the Silicon Valley where I led the open source and Web 2.0 research efforts. I am now a Professor of Computer Science specializing in open source at the University of Erlangen-Nuremberg.

On the top floor of Business Software applications, there are no viable open source offerings, there is only SAP and then, somewhere, Oracle. OpenOffice, in contrast, while far from perfect, is a fine contender for office productivity software. The complexity of an office productivity suite is much smaller than that of a serious business application suite. Thus, in many organizations, OpenOffice is a real option. In particular, the public sector comes to mind.

Under Sun, OpenOffice integration with business applications was sorely lacking. If I was running Oracle’s application business, I’d make sure these days are over, and that OpenOffice integrates well with its applications offering. There are many organizations whose feature checklist for business applications includes OpenOffice integration. In a head-to-head competitive sales situation between Oracle and SAP, this will be a box only the Oracle sales rep can check off.

open source is hard for closed source vendors, (1) because they have a different risk/reward profile than startups and have a higher fear around legal uncertainties, (2) because they would have to undergo substantial and painful organizational change, easily involving lay-offs, and (3) because current sales incentives are not set up to support cross-selling open source.

This presentation is an alpha release, which is to say, I doubt I’ve nailed it all. Please tell me what you think I’ve missed or where you dis/agree with my thoughts! Because of this, I maintain full copyright of the presentation. Later revisions will hopefully include your feedback (and give proper credits) and will be released under the Creative Commons BY-SA 3.0 license.

The presentation is available as a PDF file.

Commercial open source software projects are open source software projects that are owned by a single firm that derives a direct and significant revenue stream from the software. Commercial open source at first glance represents an economic paradox: How can a firm earn money if it is making its product available for free as open source? This paper presents the core properties of commercial open source business models and discusses how they work… [more]

The talk slides are available as a PDF file and are licensed under the Creative Commons BY-SA 3.0 license.

For a discussion of the talk’s contents I recommend reading the original article.

The Intellectual Property Rights Imperative of Single-Vendor Commercial Open Source

Always act in such a way that you, and only you, possess the right to provide the open source project under a license of your choice.

For those familiar with the dual-license strategy, this is probably a no-brainer, but I thought it would be good to spell it out and put a name on it. This helps fine-tune behavior and improve on it. One such possible improvement is the switch from a copyright transfer agreement to a relicensing rights grant.

Most notably, all commercial open source vendors I know who use a dual-license strategy require that outside code contributors sign over the copyright to their code contributions to the vendor. MySQL, SleepyCat, Jaspersoft—they all do or did it. If I was a potential contributor, I’d hate loosing the rights to my code; hence I’m less inclined to even consider contributing. This dovetails nicely with the recent debate about “GPL vs. Apache” which is all about reducing friction in building your community.

So why not weaken your contributor agreement? The intellectual property rights imperative says nothing about the firm maintaining the copyright. All you really need, as Larry Augustin pointed out to me by email, is to maintain the relicensing rights. Thus, you could ask a contributor to sign a rights grant that allows the firm to relicense his or her contribution. This is much weaker than a copyright transfer and, so my guts feeling, is likely to be received more friendly by your potential contributors. Thus it should help you to grow your community faster.

I’m sure the intellectual property rights imperative holds. I’m not sure about switching to the relicensing grant, mostly because I don’t see people doing it, so I may be overlooking something. IANAL, as they say…

Underlying the “which license?” discussion is the assumption of a dual (or multiple) license strategy, in which the free community edition of the project is available under an open source license, while the vendor is selling an enterprise edition under a commercial license. A good read for this strategy is Mike Olson’s account of it. Of course you may also like my summary.

The classic choice for the community license has been the GPL. The GPL supports building a community of users and customers while stalling competitors through its reciprocal nature, as Savio Rodriguez (and many others) observes. How is that? Because of its reciprocal nature, no potential competitor could take the project and create a competing version without having to contribute back any enhancements to the community. Thus, no chance of creating a sustainable competitive advantage over someone else. The only 800 pound gorilla will be the original creator of the project who has to make sure it maintains the relicensing rights (to its version). Practice so far has borne out that this works.

The choice of GPL for the community license has now come under fire. Eric Raymond calls it “an admission of weakness” and Matt Asay argues that the Apache license creates more openness and hence more opportunity.

I think the “GPL vs Apache” discussion is a red herring. It is a good discussion though, as it keeps clarifying thoughts, and it is good to see that we can have a sound and reasoned discussion. The arguments as I see them are:

• Both licenses help create a community.
• The more permissive Apache license increases the risk of a competitor ripping you off.
• At the same time the Apache license helps you build that coveted community faster, cheaper, better.

To me then, the choice of a license becomes a function of the stage, state, and speed the single-vendor commercial open source firm is in.

• Is the firm young and early? Inexperienced and just starting out? A bunch of guys and gals in a garage? At this stage in a startup’s life the firm may want to go for the extra protection that the GPL offers. Raymond may call it a sign of weakness, but then, it’s true, and the firm would be foolish not to acknowledge this.
• Does the firm have reasonable funds? A brand and website and alliances that help it get recognized and that drive traffic? Is it confident it can compete on innovation around its own product? Then the firm may be ready to swim with the sharks and switch to Apache. The more permissive license lets you take up more speed and grow your community faster.

While every firm is different, my best guess is that a single vendor open source firm should start out with the GPL and switch over to Apache when it thinks it can take the extra heat.

“A commercial open source firm is a software firm that provides most or all of its product as open source while maintaining the relicensing rights to the source code.” (Maintaining the rights has the purpose of being able to sell the product to customers under a commercial license.)

This type of software firm has quickly become important and stands to gain even more ground. According to Gartner Group:

“By 2012, at least 50% of direct commercial revenue attributed to open-source products or services will come from projects under a single vendor’s patronage.” From: Mark Driver. “Predicts 2009: The Evolving Open-Source Software Model.” Gartner Inc, 2009.

These firms employ various models and strategies, for example, the open core model (local copy) or the dual-license strategy. We understand a lot about them, but what we don’t have is a good category name. Calling these firms “commercial open source firms” suggests that other companies like Red Hat are not commercial open source firms. Also, selling services for a community project like Linux makes you what if not commercial.

One solution is to disambiguate by prefixing the term. For example, we could start calling SugarCRM, Alfresco, Jaspersoft, etc. “commercial single-vendor open source”. I think this is my preferred solution. We might even drop the “commercial” part as it is implied in “single-vendor” open source.

The most correct term to capture “single vendor patronage” would be proprietary. That’s because there is only one proprietor, as Christof Wittig, former CEO of db4objects, suggested. While technically correct, I fear talking about “proprietary open source” will create only more confusion.

I’m curious: Did anyone solve that naming problem? For now I’ll go with single-vendor open source.

UPDATE

I noticed that James Dixon uses the term “single-vendor commercial open source” in his Beekeeper model, so this makes at least two of us who are unhappy with the use of “commercial open source” to mean the category that SugarCRM was originally trying to identify. In James’ case, the term seems to have been introduced to distinguish single-vendor open source firms from firms providing support to community-owned open source projects.