March articles

I ended up only writing one article for this month, but it turned out to be pretty popular, garnering well over 10,000 views. However, that’s nothing compared to the over one million views the whole site had in the month of March. The final total is roughly 200,000 more than the previous monthly record. I’d like to congratulate the editorial team, my fellow Community Moderators, and all of the other Red Hat & community contributors who have worked so hard to reach this milestone. I’m honored to be a part of such a great team.

December articles

Here are the articles I wrote for in December:

November articles

I’ve decided to make this a regular thing: near the beginning of every month, I’ll recap the articles I’ve written for in the previous month. This seems better than scattershot posts that may or may not include all of my articles. So here’s November:

I support Software Freedom Conservancy

If you’ve read this blog for any length of time, you know that free and open source software is important to me. It’s important to Software Freedom Conservancy as well. Conservancy is a 501(c)(3) organization dedicated to supporting software projects.

Conservancy provides a lot of services to member projects, including financial and administrivia. Conservancy also provides license enforcement services, including support of a high-profile suit against VMWare. Although Conservancy uses litigation as a last resort, it’s sometimes necessary. However, this has lead to some corporate sponsors pulling their funding.

In order to continue their efforts, Conservancy is moving to an individual-supporter model. I first became a Conservancy supporter last year, and when it’s shortly time to renew my support, I will contribute double. Free and open source software is important to my personal and professional lives, and the services Conservancy provide to projects is invaluable.

If you use computers at all, a Conservancy project is probably an important part of your daily life. Please join me in supporting the Software Freedom Conservancy with a tax-deductible* donation today.

*Consult your tax professional to see if donations are tax-deductible in your jurisdiction.

Recent posts

In lieu of original content, here are a few articles I’ve recently written for

Selecting an open source license for VC funding

Tomasz Tunguz recently had a post exploring the relationship between open source licenses and exits (either funding or acquisition). When I first saw this, I was excited. The practical consequences of license selection is an area of particular interest to me. Sadly, the article was terrible.

Tunguz compares funded project license distribution to total open source license distribution. This is a fatal flaw since there is no evidence to suggest that these are drawn from the same population. Many open source projects are small hobbyist efforts. Even large ones can be predominantly volunteer-driven, with no intention of seeing venture funding or acquisition. That alone is enough to render the comparison meaningless. A better study would examine projects looking for funding and see if any license is correlated with better results.

The article is titled “Which Open Source License Should Your Project Use if You Want to Raise Venture Capital?” but fails to answer the question. It does not even establish whether or not the license selection matters. Even if a full statistical study wasn’t feasible, commentary from a variety of VCs could help provide guidance.

Licenses are chosen for a variety of reasons. Some are philosophical, some are practical. Choose the one that fits your project best. If that means finding out which licenses the VC firms you’ll target prefer, do that. If it means using the license that’s common to the ecosystem your project lives in, do that. Just don’t rely on a few slapped-together bar charts with no credibility.

Licensing and open source communities

At FOSDEM 2014, Eileen Evans gave a talk entitled “Licensing Models and Building an Open Source Community“. The talk is basically a discussion how Evans changed her mind about the suitability of permissive licenses in vibrant open source communities. She proposes that a vibrant community requires excellent technology, suitable governance, and a license that the community perceives as fair.

A decade ago, Evans was working at Sun and considering what license to use for OpenSolaris. The decision at the time was that because copyleft licenses require downstream changes to be returned to the community (in the sense that they remain freely-licensed), copyleft licenses are necessary for a healthy community.

In the intervening years, many projects have adopted permissive licenses. The GPL family is no longer the majority license, according to several surveys. Vendor participating in open source projects favored strong copyleft until around 2006, but the preference has shifted toward permissive licenses. A survey of GitHub projects showed the MIT license with a dramatic lead over the next-most-widely-used license.

Based on this, Evans concluded that permissive licenses can, in fact, be used

Is that still true today? Projects are increasingly using permissive licenses. MIT dominates GitHub. Vendor engagement (participation in projects) was toward strong copyleft until ~2006 when permissive licenses take over. 5x increased in contributors to CloudStack after changing from copyleft to permissive. Permissive licenses may be used to build a community.

Of course, there are few who would take the position these days that permissive licenses can’t be used. Even noted copyleft advocate Bradley Kuhn can be heard agreeing on the video, though he points out his view that copyleft licenses make for better communities. Perhaps the question should be phrased as “what kind of communities develop?”

In conducting research for my thesis, I came across a study that showed copyleft licenses were associated with higher user engagement, but permissive licenses were associated with higher developer engagement. This makes sense, since not all developers develop FLOSS. A developer who isn’t developing FLOSS would probably be more drawn to a project where the license was conducive to proprietary downstreams.

Evans’ anecdote about the increase in contributions to CloudStack when it switched from copyleft to permissive licensing may or may not tell us something. It may be purely coincidental. An increase in the popularity of the project or of cloud computing generally may have driven the change. And of course, there’s more to a community than the number of committers.

I suspect that the license itself may be less important than the overall governance model. It’s certainly an area that merits further research.

The Fundamental Theorem of Developing FLOSS

Recently Fedora developer and all-around good gal Máirín Duffy has been working on what she calls “The Fundamental Theorem of Developing FLOSS“. Inspired by what she called “opinionated non-doers”, this is an attempt to catalogue the sorts of behaviors a FLOSS developer should expect. Most of the entries revolve around change, particularly the addition or removal of features.

This isn’t some “those damn lusers” screed. Instead, Máirín offers a fairly objective summary of the experience of her and others. It’s a rather useful, if cynical, checklist of the kinds of feedback a developer might expect when introducing a change. Knowing what will happen in advance allows a project to better communicate the reasoning and impacts for a change (though the Axiom of Assuming the Worst would suggest this is a futile effort).

If I were to claim any beef with the theorem as it currently exists, it would be the Axiom of Ignoring the Source. It’s not that it’s wrong, necessarily, but that it’s incomplete. There are certainly those who are capable of reading the source, making changes, and submitting those change and yet decide not to. Sometimes it’s laziness, sometimes there are other reasons.

But there are a lot of people, and I would generally count myself among them, who lack the ability to understand the source or to make the changes I want. I think we, as various open source communities, often assume the hypothetical user is as knowledgeable as the developer and forget about the non-developer users. “Whining in an online forum” is often as much as someone can do (though it’s certainly not a productive way of expressing discontent). I’d also argue that access to source is not “the entire point” of FLOSS, but instead a means to an end. That’s more of a semantic quibble than any actual disagreement.

I suspect there’s a Fundamental Theorem of Using FLOSS to be written that is the user perspective of some of the same issues.

Impact of license selection on open source software quality

I’ve made several vague references to my master’s thesis on this blog, but I’ve never said much of substance. Your long wait is over though, as I’ve finally gotten around to uploading it and creating a research page on the website. If you don’t want to read the full thesis, there’s a condensed version that was presented at a conference in March (and won best paper in the session, I might add).

The even more condensed version is that my research shows (to my dismay) that copyleft projects tend to have higher technical debt than permissively-licensed projects. What’s more interesting than the results is the pile of questions that it brings up.

I’ll admit that my methods are not necessarily the most stringent, particularly when it comes to how quality is proxied (or even the quantification of technical debt). My methodology was partly driven by convenience and partly driven by the dearth of research available on the topic. Of course, the steep price of the C/C++ plugin hampered my ability to get a good sample.

I hope someone else picks up where I left off and does a more detailed analysis. For my own part, I hope to be able to conduct some research in my “spare time”. In addition to the mere study of differences in debt, I’d like to see how non-license project governance affects software quality. There was no analysis in my study of developer quantity, funding, etc. The ultimate goal is to develop concrete recommendations for FLOSS project leaders that would improve the quality of the finished product.