In The Diff, Byrne Hobart looks at the joys and pains-in-the-ass of open source software development:
“How university open debates and discussions introduced me to open source” by opensourceway is licensed under CC BY-SA 2.0
We’re in a strange in-between state where software is increasingly essential, the most important bits of it are built by dedicated volunteers, and there’s no great way to encourage them to a) keep doing this, and b) stay motivated as the work gets less and less fun. That was my main takeaway from Nadia Eghbal’s Working in Public, published this week.
The book is a tour of the open source phenomenon: who builds projects, how they get made and updated, and why. This is an important topic! Almost all of the software I use to write this newsletter is either built from open source products or relies on them: the text is composed in Emacs, on a computer running Linux; I browse the web using Chrome, which mostly consists of open-source Chromium code; my various i-devices run Unix-based OSes (iOS is not open-source, but there are as many open-source implementations of Unix as you want); etc. All of this software Just Works, and I don’t directly pay for any of it. Clearly there are some incentives at work, or it wouldn’t exist in the first place, but generally the more complex an activity is, the harder it is to coordinate without pricing signals. Somehow, open-source projects don’t fall victim to this.
As Working in Public shows, they do face a demoralizing lifecycle. When a project starts, it’s one coder trying to solve a problem they face, and trying to solve it their way. Sometimes, there’s a good reason their preferred solution doesn’t exist yet, and the project languishes. Sometimes, the project catches on, acquiring new users, new contributors, and new bug reports and feature requests.
[…]
Software projects go through this exact cycle: at first, they’re mostly producing and building on “software capital,” code that executes the underlying logic of the process. Over time, more of the work involves integration and compatibility, and as all the easy edge cases get identified, the remaining bugs are a) disproportionately rare (or they would have been spotted by now) and b) disproportionately hard to fix (because they have to be the result of a rare and thus complicated confluence of circumstances). So, over time, a software project falls into the Baumol Trap, where high productivity in the fun stuff produces more and more un-fun work where productivity gains are hard to come by.
This is depressing for project creators. Early on, they have the triumphant experience of building exactly what they want, and solving their nagging problem. And the result is that they’re cleaning up after a bunch of requests from people who are either annoyed that it doesn’t work for them or have unsolicited feedback on how it ought to work. No wonder Linus Torvalds gets so mad. Running a successful open source project is just Good Will Hunting in reverse, where you start out as a respected genius and end up being a janitor who gets into fights.
Emphasis mine, not in the original article.
H/T to Colby Cosh for sharing the link.
