This article is a stub. You can help the IndieWebCamp 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 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.
- Tent.io has been pitched (no pun intended) as a single project distributed social network solution.
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).
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?
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
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.
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.
Potential antidotes to monoculture:
- Encourage monoculture projects to support 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.