The De-Democratization of Online Publishing

One of the wonderful things about the rise of the web, twenty-something years ago, was the way in which it democratized publishing – suddenly, anyone with an idea could set up a website and make them available to anyone. Early on, publishing online required at least a rudimentary understanding of code. To be an online writer meant you also had to be a coder. But, services quickly emerged that created WYSIWYG editors for online publications, so literally anyone who had used a word processor could create online content.

Recently, however, we’ve seen the rise of proprietary formats like Google’s AMP, Facebook’s Instant Articles, and the Apple News Format, which threaten to de-democratize publishing on the web. To be clear, I’m not making a philosophical argument about the closed nature of these platforms but something much more practical: creating content for these formats reintroduces a coding requirement and online code is vastly more complicated today than it was in the mid-1990s.

A personal history

I first encountered the web when I entered university in 1994. It was a pretty primitive thing back then, with very limited ways to access it, and it was almost entirely text-based. But over the next four years, things moved forward rapidly, with additional web browsers improving the process of browsing the web and hosting and other online services making it easier for ordinary people like me to set up an online presence. By the time I graduated in 1997, not only was browsing the web a big part of my life but I had a website of my own. In order to build that website, I had to learn HTML which, at the time, was a very simple thing to grasp, at least at a basic level. But that coding requirement still prevented many people from creating an online presence.

Interestingly, I basically took a two-year break from the web between early 1998 and early 2000 while I was serving as a missionary in Asia. When I returned, the web had again moved on significantly. Blogger had launched in 1999 and was one of the first sites that enabled people to create their own websites without knowing anything about coding, web hosting, or any of the other more technical aspects that had previously characterized online publishing. Almost all of my online publishing since has been based on various blogging platforms and, for the last ten years, almost exclusively on self-hosted WordPress sites. Along the way, because I’ve always had something of an interest in coding, I’ve beefed up my understanding of HTML, grappled with CSS style sheets, and even done some messing around with PHP. But I’m always enormously grateful I don’t have to try to build sites that would perform well from the ground up – I’ve long since given up on that idea.

Enter AMP, Instant Articles, and Apple News

So much for my personal history. Since last summer, we’ve seen what I’d argue is the latest phase in this online publishing evolution. It involves the creation of a variety of proprietary formats for online publishing. Google has been spearheading the Accelerated Mobile Pages project (AMP), which launched officially almost a year ago. Facebook introduced its Instant Articles format last summer, with a similar objective of accelerating the delivery of articles on mobile devices. And Apple introduced News as part of iOS 9, opening it up to publishers over the summer and to most users in the Fall, albeit with different intentions.

Here’s what’s these platforms have in common, however: each uses proprietary formats to deliver articles to readers. Technically, these formats use standards-based elements – for example, AMP is a combination of custom HTML, custom JavaScript, and caching. But the point here is the outputs from traditional online publishing platforms aren’t compatible with any of these three formats. And, in order to publish to these formats directly, you need to know a lot more code than I ever did back in the mid-1990s before the first round of WYSIWYG tools for the web emerged.

As a solution, each of these platforms has provided tools intended to bridge the gap – all three, for example, have WordPress plugins to convert content to the appropriate formats. But a quick read of the reviews for the Facebook and AMP plugins tells you they don’t seem to be doing the job for many users. The Apple News plugin has a higher rating, but I know from my own experience that it’s problematic. Both Facebook and Apple also offer RSS tools to import existing content but there are limitations around both (Apple News doesn’t allow advertising in RSS-driven publications, while Facebook IA requires a custom RSS feed with IA-specific markup, which is again going to be beyond the ken of most non-coding publishers). Apple news offers a WYSIWYG tool, but it’s extremely basic (it doesn’t support embeds, block quotes, or even bullet points).

Why does all this matter? After all, no one is forcing anyone to use any of these formats – publishing to the open web is still possible. While that’s technically true, at least two of these formats – AMP and Instant Articles – are being favored by the two largest gatekeepers to online content: Google and Facebook. Google now favors AMP results in search, while Facebook does the same within its News Feed, though less explicitly (by favoring faster-loading pages, it gives IA content a leg up). Apple News is different – it’s a self-contained app and it’s basically irrelevant to you as a publisher unless your readers are using it. But if you do decide to use it, unless you publish in Apple News Format, you can’t monetize your content there and Apple is pushing the News app heavily to its users.

Turning back the clock

The upshot of all of this is, unless you’ve comfortable with fairly advanced web coding, or can pay someone who is, your online publication is likely to become a second-class citizen on each of these new platforms, if it has a presence there at all. And, as these platforms – especially AMP and Instant Articles – suck up an ever greater proportion of online content, that’s going to leave smaller publishers out in the cold. That, in turn, means we’re effectively turning back the clock to a pre-web world in which the only publishers that mattered were large publishers and it was all but impossible to be read if you didn’t work for one of them. That seems like an enormous shame and, from a practical standpoint, matters a lot more to me as an online writer than more philosophical debates about open vs. closed platforms.

Published by

Jan Dawson

Jan Dawson is Founder and Chief Analyst at Jackdaw Research, a technology research and consulting firm focused on consumer technology. During his sixteen years as a technology analyst, Jan has covered everything from DSL to LTE, and from policy and regulation to smartphones and tablets. As such, he brings a unique perspective to the consumer technology space, pulling together insights on communications and content services, device hardware and software, and online services to provide big-picture market analysis and strategic advice to his clients. Jan has worked with many of the world’s largest operators, device and infrastructure vendors, online service providers and others to shape their strategies and help them understand the market. Prior to founding Jackdaw, Jan worked at Ovum for a number of years, most recently as Chief Telecoms Analyst, responsible for Ovum’s telecoms research agenda globally.

14 thoughts on “The De-Democratization of Online Publishing”

  1. “proprietary formats like Google’s AMP, Facebook’s Instant Articles, and the Apple News Format”. Not quite. You’ll guess which one isn’t closed.

    FB and Apple make you
    1- use a closed spec to format your content, and
    2- use their closed platforms to deliver it
    3- use their closed app/ecosysem to access it…
    4- …via your account on their ecosystem

    Google’s AMP does none of the above. It’s a subset of HTML and jscript,plus some coding conventions; it works in a regular browser (no specific app to install), off the web (no specific proprietary distribution mechanism though Google is offering free optional cache services) and does not require any user account.

    1. None of these things would be an issue, as long as there were open access to these platforms. As you describe, only Google has it.
      That user’s, especially tech knowledgeable users, don’t toast these issues boggles my mind.

    2. I said exactly this in the text (see second para under “Enter AMP, Instant Articles, and Apple News”). It’s the combination of these elements (including caching) which is proprietary, and the point is that you wouldn’t need this specific combination for anything other than AMP, so it still requires customization relative to standard web content. And that customization in turn requires coding (or you can use the plugins which currently have such terrible reviews on

      1. But that’s not what proprietary means.

        The way I understand it, you’re bothered by having to publish your content to 3 different, incompatible, poorly-tooled silos (on top of the regular silos, web, RSS, mail, tweeter, which are painless because they’re well-tooled and mostly/somewhat compatible+integrated).

        I understand that’s a triple bother. But that’ doesn’t mean that they’re proprietary; 2 of them are, one isn’t, and using the term “proprietary” to mean “fragmented” or “different” + “poorly-tooled” is an issue because the definition and consequences of proprietary are way deeper than ” I have to publish/format/code/maintain my content 3 times”.

        The tooling issue will presumably go away on its own. The proprietary issue won’t, and it’s actually getting worse.

  2. “To be clear, I’m not making a philosophical argument about the closed nature of these platforms”
    Perhaps you should consider it… not the proprietary nature, the closed access, censoring nature.

    Imagine that, someone else deciding whether you can monetize your work, or discriminate search results. This runs contrary to the very notion of the internet, which was developed and initially deployed with public funds.

    1. That isn’t the focus of this piece, but I have spoken and written about it elsewhere, and it’s been well-covered by others. I’m not denying it is an issue – just wasn’t what I wanted to write about today, which is a less philosophical, more practical, concern.

  3. I think it’s actually much worse than that. Even if you’re a small publisher who’s *very* comfortable with code, each of these new platforms represents a huge time commitment to set up, and also to *maintain*. It’s bad enough that it’s a huge project to set up, but I do so knowing that there are now many more ways for my site to break, many more places I have to test changes, and any kind of redesign or rebranding will now be a much larger project.

    1. I agree it’s a pain. I do web work and we’ve been dealing with this kind of thing for years now with the rise of social media. We have to pick a handful of platforms that we think will deliver the best ROI and tailor content for each. These new publishing platforms seem very much like that, you have to pick which ones have an ROI for your specific case. Just as with social media it won’t be practical to publish on every platform, and it may not even be a good idea, if the audience you need to reach doesn’t use one or any of the platforms (in a significant way) it won’t make sense to put effort into it.

    2. It’s a good point – even if you put in the work for one, many publishers will want to do it for all three (and more). I don’t do IA or AMP today, but do publish to Apple News, and even just that is an additional step that’s often time consuming because the WordPress plugin fails to deliver the content properly more often than not.

  4. I do some client work using Squarespace, it already supports Apple News and Google AMP, you can publish content from a Squarespace blog to either platform, no coding needed. As far as I know Squarespace doesn’t support Facebook Instant Articles, but given that there are plugins to convert content for WordPress and Drupal I imagine it’s only a matter of time.

Leave a Reply

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