We are researching the governance of open source software foundations. We are specifically interested in what we call open source user consortia, that is, open source foundations where the users of the software are in the driver’s seat.
Open source software and patents are a tricky topic and resolution of the many hairy issues may need new and/or revised laws. Fraunhofer Gesellschaft is currently running a survey for the European Union to gather broad stakeholder input on the topic. I encourage participation. Deadline is Nov 30th, 2018.
I was recently pointed to a German bank’s AGB (general purchasing terms and conditions), which contained the following clause:
9.5 The SUPPLIER guarantees that as part of provided services no open source software has been used.
I think such a clause warrants a deeply humored #MUWHAHA.
Digital Ocean just published a survey of developers that indicates how companies are getting more comfortable with using open source, but remain much less comfortable with contributing to open source. Matt Asay and Chris Aniszczyk picked up on this, suggesting that open source will become more sustainable if we get those contribution numbers up. What is it that is keeping companies from letting their developers contribute?
Here is a representative experience from some recent consulting activity of mine. I asked:
So what about your open source policy?
The first manager answered:
Uh, I don’t think we have one.
The second manager:
Not true, our policy is not to do it.
The third one, somewhat puzzled:
Uhm, what about this Eclipse plug-in we are developing?
Open source license compliance is not for the faint of heart. Among many things, a company needs to tell the recipients of a distribution which open source software is used in their products. In the case of mobile apps, free or not, the user is the recipient and the app is the distribution. Downloading an app from the app store makes me a user. Lets see what we can learn about open source using an example app.
The following four screenshots show how I made my way from finding an app through installing and starting it. I could not find any information about the distributed open source code along the way.
This is obviously wrong. The use of dual licensing and the ability to provide superior service for open source are unrelated forms of competitive advantage, and without further circumstances, a business should exploit both advantages. Let me explain.
Dual (or multiple) licensing is a strategy, in which a company develops software, releases it under an aggressively reciprocal (“viral”) license like the AGPLv3 and then offers commercial customers who don’t like the open source license the option to acquire a proprietary license for the software. This is a positional advantage of the vendor, because it is the only company that can apply this strategy (courtesy of being the copyright holder). While I mix things up a bit, it is closely related to what’s been called the open core model or single vendor open source. To maintain this positional advantage, vendors need to follow the commercial open source intellectual property rights imperative.
Update 2018-10-16: MongoDB is facing the same problem and decided to go closed source, see the press release.
The brouhaha around Redis Labs taking some enterprise modules of its popular open source in-memory database Redis closed source has somewhat calmed down. However, I didn’t see any discussion of what I thought was the most interesting conclusion of the affair: A core strategy of commercial open source,
the dual-licensing of the software under an aggressive copyleft and a commercial license may not work when cloud providers are involved.
Much open source research assumes that all open source projects are alike and that if you take enough of them, you can claim generalizability for your conclusions. GitHub is the main source of such mischief, because of its size and availability.
If GitHub was like Berlin, and projects on GitHub were like the people of Berlin, then treating all projects the same is like saying that a person from Mitte is like a person from Kreuzberg is like a person from Spandau.
An open source software user consortium is a non-profit organization (foundation, consortium, working group) created for the purpose of funding and managing the development of non-differentiating open source software made available to foundation members and the general public. Its purpose is to establish a software ecosystem in which vendors and suppliers can provide products and services on an equal playing field to the software user companies. User companies are everyone who needs software and who is not a software company.
We are currently sampling what’s out there (and there is plenty, see recent prior posts on the topic). Examples are the Kuali Foundation or the openKONSEQUENZ consortium or the OpenMDM working group. For sampling, we want to understand the differences between these organizations.
Abstract: Free/Libre and Open Source Software (FLOSS) communities are composed, in part, of volunteers, many of whom contribute infrequently. However, these infrequent volunteers contribute to the sustainability of FLOSS projects, and should ideally be encouraged to continue participating, even if they cannot be persuaded to contribute regularly. Infrequent contributions are part of a trend which has been widely observed in other sectors of volunteering, where it has been termed “episodic volunteering” (EV). Previous FLOSS research has focused on the Onion model, differentiating core and peripheral developers, with the latter considered as a homogeneous group. We argue this is too simplistic, given the size of the periphery group and the myriad of valuable activities they perform beyond coding. Our exploratory qualitative survey of 13 FLOSS communities investigated what episodic volunteering looks like in a FLOSS context. EV is widespread in FLOSS communities, although not specifically managed. We suggest several recommendations for managing EV based on a framework drawn from the volunteering literature. Also, episodic volunteers make a wide range of value-added contributions other than code, and they should neither be expected nor coerced into becoming habitual volunteers.
Keywords: Community management, episodic volunteering, free software, open source software, peripheral developer, volunteer management
Reference: Ann Barcomb, Andreas Kaufmann, Dirk Riehle, Klaas-Jan Stol, and Brian Fitzgerald. “Uncovering the Periphery: A Qualitative Survey of Episodic Volunteering in Free/Libre and Open Source Software Communities.” Transactions on Software Engineering. To appear.
The paper can be downloaded as a PDF file.