Links - 16^th June 2019

These questions echo the choices that OSS projects must make:

1. Which features are used the most?

2. Which desired features are missing?

3. What kinds of users does this project currently not serve?

4. Does this planned feature benefit one group at a cost to another?

5. Will this planned feature affect a user who already depends on this project?

This is part of what makes an OSS maintainer’s job so demanding: they’re charged with making decisions on behalf of a community as a whole. They also set the tone for governance. In other words, they decide how decisions get made, which is the most momentous decision of them all.

Physical infrastructure calls for large initial investment but has low marginal costs. For example, the construction and overall maintenance of a new road is expensive, but each additional car that uses that road doesn’t much increase the cost. However, the more cars use the road, the faster it wears out and the more traffic slows.

It would seem that OSS need not worry about gridlock. After all, software’s duplication and distribution costs are effectively zero. But OSS has real marginal costs; they’re just less conspicuous. Every time someone pulls down a new dependency, the maintainer of that package has an additional person who might ask questions, demand a new feature, or open a pull request. As a project scales, the workload of supporting its users grows with it. This manifests as unresolved issues piling up, unmerged pull requests, and shrill commentary that stresses out the maintainer but offers little in the way of help.

There’s an asymmetry between the low cost of community participation and the high cost that others' participation places on the leaders of the community. Over time, this becomes a problem for users of the project, too. If the maintainer of a package you depend on is already inundated with requests, they may not have time to help out when you run into a problem or request a new feature.

This problem has a lot in common with automobile traffic. Each car on the road increases congestion for everybody else, but individual drivers don’t pay for the congestion they create. Freed from that expense, drivers are incentivized to get in their cars despite the possibility of traffic. However, the more drivers there are on the road, the more likely they’ll end up in gridlock.

[…]

In the realm of OSS, the duplication cost of software is zero, but the cost of maintenance and support is not. This burden is borne especially by maintainers. Meanwhile, it’s all too easy for users to add to a maintainer’s workload — a kind of cognitive congestion — in ways they, the users, don’t actually value that highly: by opening an issue without checking if anyone has asked the same question before, submitting a pull request with zero test coverage for an unsolicited feature (maintainers sometimes call these “drive-by PRs”), or just adding another thumbs-up emoji to a rude comment. In one sense, it’s a measure of a project’s success that so many users want to engage. But it puts an increasingly heavy burden on the maintainer to wade through it all. Ultimately, this outcome is harmful to everyone involved because it distracts the maintainer from higher priorities that would be of more benefit to the project community as a whole.

Using a technology or service should provide some benefit in kind to its users. We’ll call that benefit lift. Why introduce a second concept and not just talk about leverage in itself? It’s because we want a way to frame and identify the benefit not just the activity. For example, if we write a tool that 50 engineers use, instead of having each engineer write their own tool, that tool is being leveraged via re-use, but we haven’t identified the benefit. What if the tool slowed those 50 engineers down, or slowed down 20 of them? It’s very easy to get trapped here and assume simply the act of leveraging something is sufficient.

When it comes to introducing technology, two things need to happen. First we want to establish there will be some kind of lift, and do so in the context of our organisation. What works elsewhere may not work here. At the most simplistic level — is there expertise in-house or, will we have train up or hire in? Second, we want to look at classes of technology and not assess something in isolation. This is particularly important for programming language and database technologies as they tend to be foundational engineering choices that exhibit diminishing returns. The 5th programming language an organisation uses is not going to provide the same level of differentiated impact as the 2nd did. The 10th language is going to be a net-negative. For databases the diminishing return tends to be operational — to paraphrase Tolstoy, every unhappy database is unhappy in its own way. As expertise gets spread across ever smaller silos, it’s easy to get to a point where the engineering organisation itself starts to struggle under the burden of variation.

But it’s not just a matter of dressing up. A successful pretending object has to delicately balance pretending affordance with not making you look like an idiot. That’s why so many successful pretending objects are also highly functional. As anyone who’s been down the Tactical Pants rabbit-hole can tell you it’s easy to obsess for ages about exactly the right trouser configuration for your equipment (ooh-er), all with a perfectly straight face. But every now and then you have a moment of self-awareness and realise you’re just pretending to be a cop or a soldier from the future or Val Kilmer.

And of course, what you’re really doing is both things at once. You’re being practical and thinking about function and you’re pretending. But you need some plausible deniability — the functional stuff needs to be credible. Which is why pretending objects that are too obvious don’t work. You’re no longer pretending in your own head, you’re play acting in the world.

Another thing — I’ve always wondered why software/OS makers don’t do more with the power of pretending. Look, for instance, at the average desktop. It’s using a pretending metaphor — but it’s not much of an imaginative leap is it? It’s a desktop on your desk. I can see how this would have been useful in the early days, getting people used to interfaces and everything, but surely there’s more opportunity to have some fun now — to make software more compelling by adding some pretending value to it.