The Open Source Entitlement Complex
Why I don’t spend my free time doing what some random dude on the internet wants.
Free / Libre and Open Source Software
FLOSS is a combination of two concepts: Free / Libre Software and Open Source Software.
Free / Libre (I just say “Libre Software”) is a political movement and a formally defined set of freedoms (paraphrased for brevity):
- run the program as you wish, for any purpose
- study how the program works, and change it
- redistribute copies
- distribute copies of your modified version
- a technical community writes and maintains the software
- there is no charge to use the software
- the source code is available
Naturally, with a reputation like this, businesses love OSS because it saves them money, and engineers love FLOSS because it saves them time (and allows getting into technical details).
Why do people think FLOSS exists?
In my experience, business people tend to believe that FLOSS projects exist as a way for developers to get some exposure, and are deeply suspicious about the quality of such projects: equating gratis with cheap. But they are more than happy to take cheap over expensive!
Engineers often assume that FLOSS is about sharing knowledge. You’re written something great, of course you want to share it with the world. There is also a suspicion that it’s about fame: that the authors are doing it for attention or to feel part of a larger movement like the Apache Foundation.
Typically there is an assumption that the authors are dedicated to maintaining the project and fixing bug reports.
Why do people write Open Source software?
Most of the FLOSS developers I know subscribe to what I call the OSS developer mindset.
Such developers take great pride in what they are creating and they get a buzz out of people using the software that they’ve written. Entire ecosystems emerge out of projects that become really successful, with the emergence of a community often being seen as an indicator of success.
These developers often feel a compulsion to fix bug reports, or implement features that users request, because they are addicted to doing a great job and want even more people to use the software.
Or the project dies, nobody uses it, and all motivation goes away.
Most OSS developers use the Apache 2, MIT or BSD licenses because they want their software to be used by as many people as possible and these pushover licenses have the lowest barrier to entry for companies.
I don’t know anybody who writes OSS for personal exposure (or they don’t admit to it), which is the opposite to what users think!
Why do people write Libre Software?
Libre Software is a political movement. Richard Stallman created the FSF as a way to ensure that the people will always have full control over their computers. He’s paranoid, so he believes that it is necessary for when the government turns on us. Unfortunately, he’s depressingly prophetic about these things.
Libre developers care more about their software’s freedoms than how many users they get. There is even an element of fairness: I never want to receive a modified binary of something I wrote without the same rights I gave you.
The Libre developer can make seemingly nonsense political decisions that harms users. A recent example of this is when GNU Emacs disabled features on proprietary systems.
A more common consequence is that Libre developers prefer copyleft licenses like the GPL, even though it might mean that less people will want (or legally be allowed) to use their software, especially if it is a library.
Unfortunately, Libre software communities tend to come off sounding a bit rude. That’s because their developers don’t really care so much about you as a user. They are building the software in — as Sebastian puts it — an ivory tower.
Why do I — fommil — write Libre software?
I started my contributions very much with the OSS developer mindset. My first success was netlib-java. I was totally obsessed with making it the most technically superior solution, responding to all bug reports, and evangelising companies to use it. And I was definitely doing it to get my name out there. When it got included in Apache Spark I was delighted: it is downloaded by ~10,000 unique IP addresses every month.
A few years ago, I resurrected ENSIME the instant I found out about it: thanks
I love GNU Emacs and IDEs never quite did it for me, even when I was contributing to NetBeans. But I still had the OSS mindset: I wanted everybody to use ENSIME.
Rory joined in the fun and we put together a solid CI with lots of test coverage, contributors started coming back, and we were hosting hack days in London with satellite groups popping up in Poland sending us really great PRs. There is a wonderful video of the evolution of ensime-server (I show up about 1:30) that highlights just how many people are involved.
Our userbase was growing and growing, with more and more demanding users, yet the contributor base stayed the same size.
I was implementing features I didn’t need, hunting down bugs I didn’t see, and it was burning me out — stealing away from my personal life.
The truth is: I don’t want users, I want contributors! That might sound very selfish, and maybe it is, but I have shifted to the Libre Software mindset.
I still want to do a great engineering job, so testing and good design is critical to me, I want to anticipate strategic things like where scala and dotty are going and be prepared for them, but I don’t want to spend time on anything that doesn’t directly benefit my — or our contributors’ — use of ENSIME. That’s not sustainable unless:
- our community sponsors developers to take on the bigger tasks
- the contributor to user ratio gets higher
The community response to the sponsorship programme has been exceptional. Thank you especially to 47 Degrees, Scalanator and all our individual supporters! I honestly didn’t believe we’d hit our target, but we did. I hope we can hit our next target and fund a second part time student developer. So if you love ENSIME, please contribute some code or sponsor a developer!
The Entitlement Complex
When I get support emails for
netlib-java, they read like customer emails to their supplier: "I need a response within 12 hours", "when can you do X?". I came up with a template response on github, but what I really want to do is tell the sender: you are not my customer, pay me or GTFO.
Nobody ever pays.
When I put together a Call for Funding, I got cold responses from every major player I know in the Big Data space. I haven't made a penny or gotten a single Scala consultancy contract as a result of my work on
netlib-java and that's including when I was bending over backwards to help users.
Unfortunately, the OSS developer mindset is easily exploited by random dudes on the internet who want to be treated like customers. And (non-maliciously) by companies who are just happy taking it and not giving back.
People feel the need to declare “until it has X […] I don’t see a reason why to even try it” or “I call your development method lazy, because you tell people to implement your project themselves”. What can be worse is the passive aggressive user, who tries to make themselves look good at your expense, and demands changes or they will “give up on the project”.
These kinds of communications can be very upsetting if you subscribe to the OSS mindset. But if you take the Libre mindset, it is a kind of psychological shield and you’re glad that these people move on. But make no mistake, it is still emotionally draining and that’s why Libre maintainers still burn out.
How we could be better
Libre projects could do a better job of being helpful, yet firm, with users who are starting out or experiencing problems. Better documentation is a good way to keep users from distracting developers. Users who can educate themselves are always welcome, even if they never contribute to or sponsor a project! That said, I don’t think troublesome people can be pleased with quality documentation.
Users could do a better job of reading the documentation. This last week I’ve stopped lurking on the gitter.im/ensime/ensime-emacs channel because it was clear that people don’t read the documentation, even though it pops up on first use and we have bots that respond to keywords. It’s hilarious: people swear blind that they follow the troubleshooting guide, but it is very very clear that they haven’t. So I’m trying a bit of tough love to see if it results in more people helping themselves.
And when reporting bug reports and feature requests, on any project, let’s try to be more respectful of the author’s time. Give a reproduction, and offer to help fix the problem, it is a lot more empowering than hoping somebody else will do it.
And let’s not be so mean to FLOSS developers when our bugs rot on their issue tracker, or our amazing feature requests are not implemented.
In scala particularly, I think we should start by being nicer to the
sbt authors. They bare the worst of it and they are trying their best (often in their own personal time)!