The case against open source by default

“Open source by default.” The idea is attractive, it’s something that I’ve promoted in the past, something that I still believe has value. But seeing the arc of many projects begin, end, and continue, I see more subtlety now. Here’s that subtlety, explained as well as I can.

Open source has many positive qualities. It makes security review simpler, enabling programs like HackerOne to distribute bounties to independent researchers. It sometimes enables collective efficiency, where engineers in different places, companies, schools, and contexts collaborate on the same problem when they would otherwise have duplicated efforts. And usually, the result is free to use, so people who wouldn’t otherwise have the ability to use high technology can use it.

Open source is also an ethos. Under Information wants to be free and other slogans, open source is thought of as better, in sometimes indescribable ways. Energy is spent creating projects like Librem 15, which is able to advertise an entirely free stack, except for the BIOS, which is the much-awaited next step.

I’m summarizing these points because I think they’re all valid. I’m still an advocate for open source and I think many of the benefits are real.

But the process and ideology applied uncritically and by default isn’t always the best thing - for you or the ecosystem. And I think, in many phrasings, open source by default is uncritical: many interpretations, including the ones I’ve supported, require you to work ‘in the open’ from the moment you start a project, and make the exceptions for closed source extremely narrow.

Open source isn’t about the source

Open source is a bundle of benefits and expectations.

• With open source, you can explore concepts deeply, if you’re a creative learner. I only really understand certain problems after trying to solve them from scratch.
• Socially and professionally, success in open source can make job hunts and networking much easier, because your work is out in the open, there for anyone to judge.

Expectations:

• Running an open source project means becoming a project manager, promising a release cycle and gracefully declining feature requests and placating trolls.
• Running an open source project means being a helpdesk technician, responding to day after day of legitimate and illegitimate bug reports and requests for support.
• Running a project means an expectation of future work: that there are milestones and that the project won’t be abandoned.

Collaboration is a cost

SARAH GREEN-CARMICHAEL: It does seem like that companies have sort of made more of a push for work to become more and more collaborative. And yet it does seem like we’re maybe talking to each other all the time and actual work is maybe not actually getting done.

JASON FRIED: Yeah, I think there’s actually an epidemic of over-collaboration and over-communication. Collaboration is something managers seem to look at and think is particularly good. Because they see activity. They see people working. They see people moving. They hear buzz. Stuff’s happening.

But real creative work, especially, is usually done quietly, solitary sort of work, where people are in a flow or in a focus mode where they’re able to just focus on the stuff and not be distracted and interrupted. It’s very hard to do really good work when you’re constantly being interrupted every 15 minutes, every 5 minutes, every 20 minutes, every 30 minutes.

from Restoring Sanity to the Office, on Signal vs Noise

Fundamentally, this doesn’t have to be the case: you could release the results of your work in public and disappear. That worked, I suppose, for Satoshi, but there are few other success stories. When open source is released without support and community, like in the case of EveryBlock being dumped on Google Code, the impact of the work is extremely limited.

GitHub, the new default platform for open source and self-titled ‘social coding’ platform, makes this abundantly clear: code is the first tab, but the rest are social features like bug tracking and project management - and they’re on by default. The reaction in rare cases where people have experimented with turning them off has been largely critical: the expectations around what a project is, including an expectation of support and maintainership, are hard to shake.

But do all projects benefit from this structure? Should anyone who wants to contribute an idea also be on the hook for answering notifications from angry users, or constructively fitting other people’s requirements into a project that already serves their own?

For successful projects, collaboration eventually becomes a net benefit: the popularity of the project encourages a ‘core team’ to join up and share in the responsibilities of maintainership. Individual contributors contribute a larger share of the work.

But it’s hard to understate the rareness of that success. For every successful project that achieves escape velocity, there are tens or hundreds for which ‘the open source community’ only means bug reports and issues that a sole maintainer is expected to manage.

Clarity of purpose

Successful open source projects are all about scope. Which problems do they attempt to solve, and which do they leave unsolved? What specifications do they go for - are you trying to support odd platforms like Windows and interpreters like Rhino, in addition to the ones you use? Defining a scope that results in a useful thing for a lot of people, without being slowed down and bloated by rarer requirements, is a huge part of the challenge.

Open by default makes scoping different, because the number of ‘stakeholders’ radically increases and their leverage is totally up to you. Do you care about the persistent Windows user who makes a strong case that their platform is important? Do you respond to the issues that call a project ‘useless’ because it doesn’t handle one specific problem?

Compare this to a project you do on your own, privately, or one motivated by some specific business requirement. It’s done when it solves the problem at hand. You know it works once you’ve used it for a while. The scope of personal projects only changes when you’re interested in new things or need new functionality, not when a project becomes popular.

Maintainership increases monotonically, and longevity is scarce

Early in 2016, I let go of 40 projects. Over the course of the year, I did something similar for Mapbox, moving abandoned projects off of the organization. While creating things is fun, the expectation of maintenance increases monotonically unless you explicitly deprecate projects, making days incrementally less enjoyable and leaving you a little bit less time for maintenance.

The thing is, while the ideals of open source are so admirable, the reality is that the people trying to live by those ideals are getting burned out. Few cite writing software as the cause - more often it’s the daily grind of comments calling projects ‘useless’.

The result of these cycles of burnout are abandoned projects, and a rising distrust of open source projects with low bus factors - few contributors and a high likelihood of abandonment.

There is a type of successful project

The vast majority of successful open source projects are reusable, general-purpose libraries. When I was writing /about/open/ for Mapbox, that’s the language I used, and I think it’s still applicable. Why this type?

• Libraries are directly used by developers, who are the people most likely to contribute back.
• Applications require a much higher degree of customer support, which eventually necessitates paid staff. They also require massive packaging, documentation, and advertising resources that a typical open source project doesn’t have.

A critical approach

I still do create a lot of new projects, and the vast majority are open. But the details of the approach have changed:

• Aim to open source reusable, modular libraries, and not too many of them. It’s better to have a few well-maintained, well-thought out projects than lots of half-finished efforts.
• When I’m tinkering, it’s sometimes fun to do it without the collaboration aspect, in order to get a little breathing room from the constant drumbeat of notifications and collaboration.
• Aim for projects that actually grow a community, and spend time encouraging contributors. This is much harder than the alternative, but the eventual impact is much, much greater.

This is adapted from Polite Technology, a guide to social interactions in open source.