monoculture

This article is a stub. You can help the IndieWeb wiki by expanding it.

Monoculture refers to the antipattern of one piece of software dominating (or trying to dominate) its field, often by being limited to communicating with other instances of the same codebase. A monoculture (same software running on servers run by different people) is one step above a silo (same software running on servers run by the same people or organization).

Examples

Examples of software monocultures that have developed over time:

Mobile WebKit: web designers that only design their mobile web content for the WebKit browser, including only using -webkit-* CSS properties or even blocking access to browsers that don't have a WebKit user-agent string.
BuddyCloud "is an open source, distributed social network"
- No one particular project should be considered a "distributed social network"
Diaspora to some degree emphasized interop with other Diaspora instances, though it did support several open standards, and thus made progress towards open interop rather than single-project-interop.
Main article: Diaspora
...

Common patterns among monoculture projects include:

don't bother to research/re-use existing working protocols (or only minimally do so)
don't bother to engage with existing healthy communities
go down the path of solving it all themselves in the project
expect others to follow their software/protocols when they didn't bother to follow anyone else's, or at least document why they considered and rejected them, or why theirs is an improvement (contrast with webmention being a deliberate improvement upon pingback).

Monoculture Community

Another slippery slope with monoculture projects is the tendency to create monoculture communities around said projects.

Having a vibrant developer / user community is a downright necessity with fledgling open source projects.

Is it? None of the fledgling open source IndieWeb projects that people here are building for their own sites have any kind of project-specific developer/user "community". Perhaps this is a false assumption of "necessity". What an open source project does need is at least one dedicated creator and you get that through relentless selfdogfooding. No amount of developer/user "community" can make up for dedicated creators (or lack thereof). - Tantek 11:43, 30 May 2013 (PDT)

However, when creating community one can make a choice which is intrinsically monoculture perpetuating (which appears to be the convenient default) or conversely a culture which fosters cross platform interoperability and compatibility.

Take for instance this prize from the stretch goal from the Kickstarter of the promising new blogging platform Ghost:

"We will build an Open Source Digital Magazine curating stories written with Ghost" Ghost blogging platform

Is it truly within the ethos of the open source software movement to create an open source magazine that only covers content written from one platform of blogging software?

Would open source not be better off if multiple projects within a given domain (e.g. content publishing) all worked together to achieve something bigger?

Past Examples

Monoculture efforts typically either evolve heterogeneous interoperability with other efforts, or they die off.

Tent.io was pitched (no pun intended) as a single project distributed social network solution.
Main article: Tent.io

Quotes

Monoculture efforts & attitudes can often be inferred by how people (especially advocates or idea-folks) talk about them. Note the embedded monoculture assumptions in the following, often ironic in a context of discussing decentralized or distributed systems:

I'm working on a platform that leverages all the above in their various capacities under one platform
— https://chat.indieweb.org/social/2021-04-13#t1618353091983500 (Emphasis added)
I want to do it to build a distributed computing mesh for the globe
— ibid, (Emphasis added, note the self-centered single-person desire&effort positioning for the "globe")

Disadvantages

There are numerous downsides to monoculture, including:

security risks — the exact same bugs on many servers mean attacks can be reused and deployed in bulk to a large numbers of servers. Examples: WordPress, MediaWiki, OpenSSL
software encodes values: what Facebook means by "liking" something is different than what Google means by "+1"-ing something, which is different than what Twitter favoriting means, which is different from what WordPress means by "starring" something. The semantics of each differ: having a wider array of software means that people can experiment with encoding a wider array of conceptualisations of the things they value into the software they use.
Open source monocultures can foster unproductive disagreement between collaborators. If everyone is working on the same project then we all have to agree on all details of implementation. Alternatively, focusing on interoperability and personal use cases encourages healthy debate without the need for anyone to compromise.
Monoculture builds up fragility debt - by making internal connections easier, at the expense of interoperation, ending in a large collapse as all connected data is lost at once. See The Antifragility of the Web
…

Perceived Advantages

Monoculture appears to have some benefits; for example the ease of implementation across different instances of the same code base.

However, this "ease of implementation" is an illusion of progress in terms of interoperability that may actually provide a motivational barrier to working on the hard problems of cross-implementation interoperability.

Avoiding

Software can avoid promoting monoculture by prioritising integration with other codebases over working with other instances of itself.

As a community we can avoid monoculture by using many different implementations and building/lobbying their developers to build them to work together.

Antidotes

Potential antidotes to monoculture:

Encourage multiple independent implementations of any specification. (see also plurality)
Encourage monoculture projects to support any or all of the indieweb building-blocks and become indieweb friendly.
Encourage participants in monoculture projects to join IRC and signup on the Guest List to attend the next IndieWebCamp. By engaging these projects productively, perhaps we can help improve them and their cross-project interop.

We should document monocultures that we have successfully reached out to and integrated into the broader indieweb community.

Articles

2010-06-04 Ben Werdmüller Building a distributed social network? You’re doing it wrong. has several examples of monoculture projects (most of which have since died). (archived)
2010-10-08 Ryan Barrett Standards or diversity? Monoculture or fragmentation?
2014-05-03 Ned Batchelder: GitHub monoculture
2016-05-25 Dave Cridland: Open Standards Monocultures and Diversity
2016-08-18 Stefan Thomas: The Subtle Tyranny of Blockchain