Tag Archives: free software

Impact of license selection on open source software quality

Posted on by
Reply

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.

 

78% of companies “run on open source”

Posted on by
Reply

Black Duck Software recently released the results of their annual Future of Open Source survey. On the surface, it looks pretty good. As the title of this post says, 78% of companies “run on open source”. Open source usage has doubled in business IT environments since 2010. Two-thirds consider open source offerings before their proprietary counterparts.

Not only are companies using open source software, they’re contributing, too. Some 64% of companies participate, with nearly 90% expecting to increase their contributions in the next few years. Half of the companies say more than 50% of their engineers are working on open source. Many companies see open source participation as a recruiting tool as well.

But when you dig a little deeper, there are some issues, too. A majority of companies view open source software as having higher quality and security, but most don’t monitor the code for vulnerabilities. Companies lack formalized policies both for consumption and contribution. A lot of the terms are pretty vague, too. “Participation” in open source can take on a variety of meanings, some of which are basically token involvement for PR purposes.

What I found most interesting, though, was the projects listed as “most valuable”: OpenStack and Docker. I may be biased by my day job, but I see that as a sign of the rise of *aaS. Despite the growth that cloud services have already seen, there’s a lot more market out there to be tapped.

Another interesting item was the increase in venture capital investment, both in gross and per-deal measures. Hopefully, this reduces the issues faced by projects such as OpenSSL and PGP, where a lack of funding puts much of the Internet’s secure communication at risk.

Finally, my initial reaction to the headline was “the other 22% do and don’t know it.” As it turns out, I wasn’t that far off. Black Duck reported that 3% of respondents do not use open source software at all. (Where’s the remaining 19%?) I actually wonder if that’s true. It seems like you’d have to try pretty hard to avoid any of it. This will become increasingly true as time goes on, when even historically hostile companies like Microsoft being open sourcing some of their products.

File a bug!

Posted on by
13

The ability for users to submit patches is often touted by advocates of open source software. “Patches welcome!” is a common refrain on mailing lists. Even if someone lacks the ability to diagnose and fix an issue, they can file a bug in the project’s system. Indeed, there’s an unwritten social expectation that users file a bug.

Sadly, these are often just empty words. “Patches welcome” can be a seemingly-polite way of saying “your problem is not important to me. Go solve it yourself and I’ll accept your solution.” And telling a user to go file a bug can be equally dismissive, especially if the bug-filing process is unpleasant.

I certainly don’t mean to imply that all or even most open source developers use these phrases as a polite cover for their disinterest. There are jerks, of course, but I suspect most developers genuinely want bug reports and patches. Last week, a very busy developer replied to a mailing list post with a terse “file a bug.” Now, I happen to know this particular developer and I know he’s keenly interested in fixing bugs. On this day, he was swamped and didn’t have time to get to the issue right away. Suspecting from the original email that the user who reported the bug wasn’t deeply technical, I took the liberty of reproducing the issue and filing a bug with the details.

Would the person who originally reported the issue have filed the bug done so if I hadn’t? We’ll never know, but I do know that he didn’t by the time I did. After creating a Red Hat Bugzilla account, selecting the right options, and filling out the bug report, he’d have to hope the developer meant it and that he bug would get fixed. As anyone who has been around a while can attest, just because a bug is filed, that doesn’t guarantee it will be fixed in the next few years.

One particular bug that I filed sticks in my memory. It was undeniably a bug, I attached a patch to fix it, and yet the bug remained untouched through several Fedora releases. Granted, it was a relatively minor issue, but if I weren’t involved with the project, I’d have been pretty put off by this. Of course, no one owes me a fix, but as Chris Siebenmann noted, if there’s a social obligation to file a bug, there’s also a social obligation to deal with the bug.

This morning,I asked on Twitter if anyone had what they’d call a “positive” bug reporting experience (as opposed to simply a not-negative experience). I was pleasantly surprised when several people chimed in to say they had. Small projects were generally the ones that drew the good responses (Jordan Sissel was mentioned by multiple people).

So what makes for a positive experience? Rapid acknowledgement and resolution were mentioned several times. Those who replied mentioned courteous and helpful interactions (e.g. asking constructive questions, filing an appropriate bug when the original bug was mis-filed). @phrawzty summed it up well: “Most importantly, however: good intentions were assumed. I never felt treated like a dangerous outsider.”

This is an area wide open for study (and I may end up doing just that), but in the meantime projects should consider how they present themselves. Large projects with more resources should make an active effort to devote some time to bug handling as a community outreach effort (I suspect large projects have worse bug experiences, in part due to the fact that nobody owns the process). When you say “patches welcome” or “file a bug”, consider what you’re really saying and if people will take it the way you mean it.

(Thanks to those who provided feedback: @cpj1, Matt Simmons, Matthew General, Patrick Cable, @phrawzty, Rick Waldron, @SysAdm Dredd, Thomas Ballinger, @Twirrim, and anyone else I failed to mention.)

elementary misses the point

Posted on by
11

A recent post on the elementary blog about how they ask for payment on download created a bit of a stir this week. One particular sentence struck a nerve (it has since been removed from the post): “We want users to understand that they’re pretty much cheating the system when they choose not to pay for software.”

No, they aren’t. I understand that people want to get paid for their work. It’s only natural. Especially when you’d really like that work to be what puts food on the table and not something you do after you work a full week for someone else. I certainly don’t begrudge developers asking for money. I don’t even begrudge requiring payment before being able to download the software. The developers are absolutely right when they say “elementary is under no obligation to release our compiled operating system for free download.”

Getting paid for developing open source software is not antithetical to open source or free (libre) software principles. Neither the OSI’s Open Source Definition nor the Free Software Foundation’s Free Software Definition necessarily preclude a developer from charging for works. That most software that’s free-as-in-freedom is also free-as-in-beer is true, but irrelevant. Even elementary touts the gratis nature of their work on the front page (talk about mixed messages):

100% free, both in terms of pricing and licensing. But you're a cheater if you take the free option.

100% free, both in terms of pricing and licensing. But you’re a cheater if you take the free option.

Simply put, the developers cannot choose to offer their work for free and then get mad when people take them up on the offer. Worse, they cannot alienate their community by calling them cheaters. Of the money the elementary receives, how much of it goes upstream to the Linux Foundation, the FSF, and the numerous other projects that make elementary possible? Surely they wouldn’t be so hypocritical as to take the work of others for free?

An open source project is more than just coders. It’s more than just coders and funders. A truly healthy project of any appreciable size will have people who contribute in various ways: writing documentation; providing support on mailing lists, fora, etc.; triaging bug reports; filing bug reports; doing design; marketing (including word-of-mouth). This work is important to the project, too, and should be considered an in-kind form of payment.

It’s up to each project to decide what they want in return for the work put in. But it’s up to each project to accept that people will take from all of the choices that are available. If that includes “I get it for free”, then the right answer is to find ways for those people to become a part of the community and contribute how they can.

Introducing the “Permissive 3000” license

Posted on by
2

Software licenses aren’t necessarily the easiest texts to understand. This issue is compounded when the person trying to understand the license is in a different jurisdiction or is a non-native speaker of English. A recent thread on the OSI’s license-discuss list brought this issue to light. According to the original poster, a project using the BSD 3-Clause license was used without attribution in a proprietary product. The developer lost the court case because the judge did not understand English well. The poster brought an attempt at a rewrite to the list, but it had some contradictions and other meaningful differences. So I thought I’d give it a try myself.

This weekend, I started from the original BSD 3-Clause license and excised all of the words not on the Oxford 3000™ word list (or reasonably close modifications, e.g. verb tense conjugations). I did make an exception for the word “copyright”, since it seems indispensable to a software license. In all other cases, I used synonyms and circumlocution in order to preserve the meaning while remaining within the constrained word list. This was challenging at times, since circumlocution can end up making the document more difficult to understand than an unknown word might. The difficulty is further compounded by the fact that many words have a distinct legal meaning and a synonym might not have the same weight.

I consoled myself with the fact that software warranties (where most of the real challenge was) are probably not that useful anyway. Furthermore, just because a word has a distinct meaning in American courts, that doesn’t mean that foreign legal systems have the same definitions. Trying to use largely U.S.-centric licenses written in English is a challenge for a global society, but I don’t know that a system of jurisdiction/language-specific licenses would be any better.

In any case, without further ado, I present the Permissive 3000 license. It’s highly experimental and totally unvetted by legal professionals, so nobody should use it for anything except a learning exercise. I’m looking forward to some constructive feedback and hopefully it sparks a discussion about how licenses can be simplified so that they’re more easily understood by judges, developers, and users alike.

Open source is about more than code

Posted on by
2

The idea of open source developed in a closed manner is hardly new. The first real discussion of it came, as best as I can tell, in Eric S. Raymond’s The Cathedral and the Bazaar. A culture of open discussion and decision making is still a conscious act for projects. It’s not always pretty: consensus decision making is frustrating and some media outlets jump on every mailing list suggestion as the final word on a project’s direction. Still, it’s important for a project to make a decision about openness one way or the other.

Bradley Kuhn recently announced the copyleft.org project, which seeks to “create and disseminate useful information, tutorial material, and new policy ideas regarding all forms of copyleft licensing.” In the first substantive post on the mailing list, Richard Fontana suggested the adoption of the “Harvey Birdman Rule,” which has been used in his copyleft-next project. The limited response has been mostly favorable, though some have questioned its utility given that to date the work is almost entirely Kuhn’s. One IRC user said the rule “seems to apply only to discussions, not decisions. The former are cheap and plentiful, but the latter actually matter.”

I argue that the discussions, while cheap and plentiful, do matter. If all of the meaningful discussion happens in private, those who are not privy to the discussion will have a hard time participating in the decision-making process. For some projects, that may be okay. A ruling cadre makes the decisions and other contributors can follow along or not. But I see open source as being more than just meeting the OSI’s definition (or the FSF’s definition of free software for that matter). Open source is about the democratization of computing, and that means putting the sausage-making on public display.