Every year, I teach the AMOS class, a lab course on “Agile Methods and Open Source” that combines lectures with a real software project that ideally turns into a startup (see the AMOS Project concept, in German). To explain open source, I have to introduce students to intellectual property rights, of which most have been blissfully unaware of until then. Nothing teaches concepts better than a colorful story, and so I have been using the IP strategies around Java to make this dry topic come alive. For fun, comments, and corrections, I’m providing the short version of my talk below, including commentary. (You can also download a PDF version of the talk, licensed as CC-BY 3.0. If you find this useful for teaching, please tell me.) Students at this point have a basic working understanding of intellectual property and exclusion rights. Please let me know what you think! Finally, IANAL.
Java is an important technology powering the modern web and in particular enterprise applications. It has a checkered intellectual property history, and with the recent acquisition of Sun, the Java creator and owner, by Oracle, things only stand to heat up. This slide set discusses some of the more interesting issues around Java intellectual property and its strategic use in business.
Open source is not only software, but also an approach to software development. The public nature of open source projects lets us show how open source software development scales to the largest project sizes. The following figure illustrates the scalability of open source software development. I call it the big bang of open source.
Following up on Matt Aslett’s excellent post about the growth of permissive licenses and a short discussion about it on my research group’s blog, I wanted to suggest here a thought about the ratio of new vendor-owned vs. community-owned open source projects. I’m ignoring existing projects because of their path dependence (read: only today do we know what we are doing). My point is being illustrated by the following figure that I occasionally use:
Update 2012-01-28: Springer changed the citation. The reference below reflects this.
Springer just republished our 2009 article on how vendor-owned open source works, again. Here is the abstract:
Abstract: Single-vendor commercial open source software projects are open source software projects that are owned by a single ﬁrm that derives a direct and signiﬁcant revenue stream from the software. Single-vendor commercial open source at ﬁrst glance represents an economic paradox: How can a ﬁrm earn money if it is making its product available for free as open source? This paper presents the core properties of single-vendor open source business models and discusses how they work. Using a single-vendor open source approach, ﬁrms can get to market faster with a superior product at lower cost than possible for traditional competitors. The paper shows how these beneﬁts accrue from an engaged and self-supporting user community. Lacking any prior comprehensive reference, this paper is based on an analysis of public statements by practitioners of single-vendor open source. It forges the various anecdotes into a coherent description of revenue generation strategies and relevant business functions.
Reference: Dirk Riehle. “The Single-Vendor Commercial Open Source Business Model.” Information Systems and e-Business Management vol. 10, no. 1. Springer Verlag, 2012. Page 5-17.
Following up on my Lisog talk earlier this month, I was asked to write up the talk’s content. So here we go, my analysis of what commercial open source firms do to manage or steer open source projects they depend on.
Abstract: Most commercial software today depends on open source software. The commercial software might be using an underlying open source platform, or it might be incorporating open source components, or it might be provided as a commercial open source product itself. Whichever the case, the software firm behind the commercial software needs to ensure that its interests are met by the open source software projects it depends on. This article shows how commercial software firms manage or steer open source software projects to meet their business needs.
It’s April 2nd, so the Apache Software Foundation’s 2010 April Fools’ joke is over. Here is why I liked it a lot. It represents a hypothetical: What if the ASF and its projects could be bought? Or, if not bought, then put under control or strong influence of corporate interests like in traditional open source consortia? It would put the very software infrastructure we take for granted under partisan control and there is no guarantee that those partisan or corporate interests would be in the interest of the public good.
These days, I get involved in a lot of discussions about open source economics. Usually, they lead to an invitation to present our research and clarify “how open source works” to the audience. I’ve found it helpful to distinguish these three rather different areas of open source economics: (1) direct profits, (2) public welfare, (3) labor market. In more detail:
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.
You may have noticed the recent discussion about which open source license a single-vendor commercial open source firm should choose for its community offering. In this blog post I’ll argue that this choice depends on the state and speed of the firm.