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.
We just finished redoing our original analysis of paid vs. volunteer work in open source for Gitee, a Chinese-dominated code hosting platform from China. We wanted to understand where China stands in open source. Previous blog posts looked at base data, e.g. the half/half split between paid and volunteer work, as well as developer behavior, e.g. that dominantly paid developers still volunteer in their spare time.
In this third and final blog post, I would like to look at projects and how commercially dominated (or not) they are. For the purposes of this analysis, a developer is a (pure) paid developer, if 95% or more of their commits are done during regular working hours, and a developer is a (pure) volunteer, if 95% or more of their commits are done outside of these working hours. Obviously, this is a very conservative definition. How commercial a project is then depends on the percentage of (pure) paid developers and how non-commercial depends on the percentage of (pure) volunteer developers. The following figures shows how many projects exist for the percentage distributions of either pure paid or pure volunteer developers. Please observe the logarithmic y-axis.
We just finished redoing our original analysis of paid vs. volunteer work in open source for Gitee, a Chinese-dominated code hosting platform from China. We wanted to understand where China stands in open source. The previous blog post explained the half / half split between paid vs. volunteer time in terms of total work on open source.
So far, we only discussed commits, now I would like to discuss committer behavior, in particular, whether there are pure paid developers, who only work Mon-Fri, 9am-5pm, i.e. during regular working hours, and pure volunteers, working only outside those hours. Compared to our data for the Western world, the Chinese data is less conclusive. The following figure bins developers into the respective categories, and the following table spells out the bins (categories) explicitly. For the figure, please note the logarithmic scale of the y-axis.