I’ve been saying for awhile now in discussions of the commons, OER, and higher education that a “commons doesn’t scale, it scopes”. Before I explain why I think a commons doesn’t scale very well, I probably need to briefly clarify what’s meant by scale and scope. Like many terms in economics, they’re both commonly used terms in both business and everyday life, but in economics they may carry a subtly different, more precise, or richer meaning. Both terms refer to the production of an increasing volume of output of some kind. Enthusiasts of particular good(s), be they an entrepreneur producing the a product they hope will make them rich or an open educator advocating for more open licensed textbooks because it will improve education, generally want to see their ideas scale. And by scale, they generally mean “be produced in larger and larger volumes”. Larger volume of output, of course, brings a larger volume of benefits to more users. More output –> more users –> more benefits. But it’s the behavior of costs that really intrigues us when we think of “scaling” as a way to increase output. More benefits is nice, but if more benefits also means an equal increase in costs, then it’s not so attractive.
I’m also reminded of a post I annotated the other day:
Data sharing and how it can benefit your scientific career (Nature)
Crowther offered everyone who shared at least a certain volume of data with his forest initiative the chance to be a co-author of a study that he and a colleague led. Published in Science in 2016, the paper used more than 770,000 data points from 44 countries to determine that forests with more tree species are more productive.
I suspect a similar hypothesis holds for shared specs, code, and the broader idea of plurality within the IndieWeb. More interoperable systems makes the IndieWeb more productive.
I also can’t help but think about a reply to a tweet by Chris Messina in relation to the IndieWeb related article in this week’s The New Yorker:
I’ve been tinkering with this again lately. Basically none of it is productized and much of the code is stale and/or only works for single user setups.
So yeah – classic car at best. What does a Model T assembly line look like for IndieWeb?
— Boris Mann (@bmann) May 20, 2019
Boris is asking a problematic question not remembering early issues with the Model T, which Jim Luke reminds us of in his article:
Remember Henry Ford’s famous quote about “the customer can get [the Model T] in any color they want as long as it’s black”?
We’ve already got the Model Ts of social media–it’s called Facebook. It’s Twitter. It’s Instagram. And they’re all standardized–black– but they all require their own custom (toxic and limited) roads to be able to drive them! I can’t drive my Model Twitter in Facebookville. My Instagramobile has long since broken down in Twittertown. Wouldn’t you rather “See The U.S.A. In Your [IndieWeb] Chevrolet“?!
The answer to Boris is that the IndieWeb has been working on the scope problem first knowing that once the interoperable kinks between systems can be worked out to a reasonable level that scale will be the easy part of the problem. Obviously micro.blog has been able to productize IndieWeb principles (with several thousands of users) and still work relatively flawlessly with a huge number of other platforms. There have been tremendous strides towards shoehorning IndieWeb principles into major CMSes like WordPress (~500+ active users currently) and Drupal (~50+ active users) not to mention several dozens of others including Known, Perch, Craft CMS, Hugo, Kirby, etc., etc.
I haven’t heard aggregate numbers recently, but I would guess that the current active IndieWeb user base is somewhere north of 10,000 people and individual websites. Once the UI/UX issues have all been ironed out even a single platform like WordPress, which could easily add the individual pieces into its core product in just a few hours, would create a sea-change overnight by making more than 30% of the web which runs on it IndieWeb friendly or IndieWeb compatible.
Yes, friends, scale is the easy part. Plurality and scope are the the far more difficult problems. Just ask Zuck or Jack. Or their users products.