Discalaimer: Please read the whole articles, the quotes are only to make it easier for myself to remember what they are about.

A Generation Lost in the Bazaar by Poul-Henning Kamp^[1] #

Quality happens only when someone is responsible for it.

Criticism of the impact that Eric Raymond's book The Cathedral and the Bazaar (O'Reilly Media, 2001) had on the tech industry. Must read.

That is the sorry reality of the bazaar Raymond praised in his book: a pile of old festering hacks, endlessly copied and pasted by a clueless generation of IT "professionals" who wouldn't recognize sound IT architecture if you hit them over the head with it. It is hard to believe today, but under this embarrassing mess lies the ruins of the beautiful cathedral of Unix, deservedly famous for its simplicity of design, its economy of features, and its elegance of execution. (Sic transit gloria mundi, etc.)

One of Brooks's many excellent points is that quality happens only if somebody has the responsibility for it, and that "somebody" can be no more than one single person—with an exception for a dynamic duo. I am surprised that Brooks does not cite Unix as an example of this claim, since we can pinpoint with almost surgical precision the moment that Unix started to fragment: in the early 1990s when AT&T spun off Unix to commercialize it, thereby robbing it of its architects.

More than once in recent years, others have reached the same conclusion as Brooks. Some have tried to impose a kind of sanity, or even to lay down the law formally in the form of technical standards, hoping to bring order and structure to the bazaar. So far they have all failed spectacularly, because the generation of lost dot-com wunderkinder in the bazaar has never seen a cathedral and therefore cannot even imagine why you would want one in the first place, much less what it should look like. It is a sad irony, indeed, that those who most need to read it may find The Design of Design entirely incomprehensible. But to anyone who has ever wondered whether using m4 macros to configure autoconf to write a shell script to look for 26 Fortran compilers in order to build a Web browser was a bit of a detour, Brooks offers well-reasoned hope that there can be a better way.

Entitlement in Open Source by Mike McQuaid^[2] #

You can think of it as advice for maintainers of open-source projects, but it's a must read for users as well.

Coping strategies #

Firstly, you should only be maintaining open source software you use yourself. This is partly because you can’t be a good maintainer unless you can empathise with your users but also because your open source work should be enjoyable and you’re unlikely to enjoy satisfying the demands only of others and not yourself.

Secondly, remember and really deeply internalise the fact that you can stop working on any open source project at any time. Open source maintenance is a job and, like a job, when it stops working for you and you have better options, you can go elsewhere. You should not feel bad about this; instead, you should feel good about the fact that every contribution you continue to make or made in the past were good deeds given freely to others. When your life or the project means it no longer feels good to work on it anymore — stop.

Third, your time as a maintainer is simply more valuable than that of your users. In Homebrew’s case, there’s 30 maintainers and millions of users. It does not scale to prioritise user time over maintainer time. In many, perhaps most open source projects there’s a single maintainer. As a result, this maintainer should only be doing the tasks that users and other contributors cannot do. Alternatively, this maintainer should only be doing the tasks that they want to do.

Finally, maintainers need to learn to say “no” again and again. No to new features. No to breaking changes. No to working on holiday. No to fixing issues or merging pull requests from people who are being unpleasant. No to demands that something has to be fixed right now.

I am not a supplier by Thomas Depierre^[3] #

Can you call it a Software Supply Chain if most of it is open-source given to you for free with a license that explicitly tells you that you can't depend on it? Something to think about.

There is a small problem here. We are not suppliers. All the people writing and maintaining these projects, we are not suppliers. We do not have a business relationship with all these organisations. We are volunteers, writing code and putting it online under these Licenses. And yes, we put it online for people to use them. But we do not get anything from it.

Hell even worse, a lot of the libraries that underpin the fabric of what we all call the digital economy have trouble getting enough money to pay for food. On this topic, I strongly advise everyone to take the time to read Nadia Eghbal Road and Bridges report to realize the depth of the problem. It is a bit old, as it was written in the aftermath of HeartBleed, but it is as relevant today as it was at the time.

Or for a funnier, more visual explanation, XKCD 2347

XKCD 2347, image of a stack of blocks, labelled "All modern digital infrastructure", with one small block holding the whole stack stable labelled "A project some random person in Nebraska has been thanklessly maintaining since 2003

And we know it. This is why in every single one of these licenses, that govern the rules to reuse the work we put online in these libraries, you will find this paragraph, copied verbatim.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

It may feel a bit legalese, and yes, it shouts at you, but I can summarise it pretty easily. If you use this, I owe you nothing. At all. We have no relationship. I put this up online on the condition that if you use it, all the risks are on you.

What it means is that there is no supply chain here. Because there is no supplier. I am not providing you something that you bought from me. There is no relationship. I put something online because I wanted to. The fact you made your product depend on it is your responsibility. Not mine. Not the one of the providers. We provide libraries. We do not supply them. You cannot apply rules to me.

Open source is stifling progress by Jonathan Edwards^[4] #

One of the unintended consequences of open-source is that zero-cost means that there is almost no market for costly/experimental/hard to make software.

Not much user-facing software is open source. But it has almost taken over software development tools. Building things for ourselves and other programmers tickles our nerd sensibilities. Nerd cred is a form of social status we have a shot at. Open source has certainly enabled a lot of software startups to get rich quickly building (closed source) software. But it also killed the market for development of better software tools. There used to be a cottage industry of small software tool vendors offering compilers, libraries, editors, even UI widgets. You can’t compete with free. You can’t even eat ramen on free. You get what you incent, and open source de-incentivizes progress in software tools.

The open source gift exchange by David Heinemeier Hansson^[5] #

That's why the gift metaphor is so helpful to settle expectations on both ends on the exchange. If you're a recipient of a gift, one offered with no strings attached, you're not entitled to much beyond the freedom of choice of whether to accept it or not. And if you're the giver of a gift, you'd be foolish to expect specific reciprocity in return.

The open source gift exchange has never been busier. The primary crisis, if there is one, is mismatched expectations between givers and receivers. Solvable by a change in perspective. Give it a try.

Feedback or Comments?

← Home

Want to learn more?

Sign up to get a digest of my articles and interesting links via email every month.