👓 Scale and Scope | Jim Luke

Read Scale and Scope by Jim LukeJim Luke (EconProph)
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 can see a relation to the economies of scope that Jim Luke is talking about here in relation to the IndieWeb principle of plurality. For a long time the IndieWeb community has put economies of scope first and foremost over that of scale. Scale may not necessarily solve some of the problems we’re all looking at. In fact, scale may be directly responsible for many of the problems that social has caused in our lives and society.

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:

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.

9 thoughts on “👓 Scale and Scope | Jim Luke”

  1. Model T IndieWeb

    Continuing the discussion of how IndieWeb needs to evolve in order to see adoption.

    Chris Aldrich responds to my question “What does a Model T assembly line look like for IndieWeb?” by first asserting that that’s what Twitter and Facebook already are.

    So I guess I’ll need to explain what I meant by asking that. No, I don’t think “Model T Assembly Line” equals Facebook. And one large MicroBlog instance isn’t it, either.

    How does an end user – I’ll call this person a tinkerer, because you’re going to at least need to copy and paste some tech instructions – deploy a site for just them, that works out of the box? And, where is the list of different “just works” solutions that they can choose from?

    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.

    Plugins to existing systems are great! But: in many cases, the base system has a high technical complexity. I personally wouldn’t feel comfortable telling people to run their own WordPress or Drupal instances – you need hosting experience and security maintenance. So right away that’s a relatively high cost.

    I’ve spent quite some time looking at this stuff, especially just recently. I just added a PR to Pelle Wessman @voxpelli’s webmentions server so that it can be one-click “Deployed to Heroku”. Pelle wants to go further and have it work in “single user mode”, but for now anyone can host their own webmentions server.

    Known is the best of the bunch that Chris lists, in terms of being fully integrated and setup out of the box. Except I think you still need to setup Bridgy separately? Bridgy seems to do everything that people actually need in terms of communicating with today’s social media world, so I don’t understand why that functionality isn’t baked in to more systems? I originally got Known working on Heroku shortly after it launched (notice a theme?) and it’s on my list to set it up this way again.

    This “Deploy to Heroku” modality (or Zeit or other serverless style) is a simpler, turn key model for both developers and end users. Especially for distributed systems, we can’t think in a mode of old school LAMP stack systems where the “user” is hand updating the operating system layer. Even Docker deploys just sort

    I want to see distributed systems where users are hosting from mobile phones to Raspberry Pis, and every mode in between. IndieWeb has the right spirit for this, and absolutely needs to work on protocols and interoperability, but it also has an issue where a lot of this code is simply stale.

    So: how do we encourage more Manton’s and Pelle’s to build Model-Ts that are one-click-deploy simple for both tinkerers and other developers?

    Syndicated copies to:

Mentions

  • Chris Aldrich

Leave a Reply

Your email address will not be published. Required fields are marked *