In my last entry on this topic, I outlined at a very high level that I felt the time had come for a fourth generation of social software. I promised at the time that I would begin my ruminations on the topic by examining the interests of the many stakeholders in the blog platform game.
Incidentally, I hate the word “stakeholder”, a word which escaped from the gambling lexicon into the synergising empowering vocabulary enablement of MANAGERIAL.
A cursory search using Google Images reveals that this word has only two (possibly) redeeming features:
- It keeps graphic design artists gainfully employed producing grids, circles, pinwheels and other pretty ways of expressing who cares about something, and
- No weird fetish porn turns up on the first search result page.
However it has been thoroughly corrupted and debased by usage in documents composed of MANAGERIAL. And so, for the purposes for this foray into the world of people who care about blogging software, I will instead use the term only slightly less odious term “participant”.
Broadly, I divide participants into three classes:
- Users, who are generally disinterested in the technical minutiae of the system;
- Developers, to whom the technical minutiae is the primary topic; and
- Technical Clients, who have some things in common with Developers, but with quite different primary requirements.
The emphasis in this essay is to focus on requirements and desires of any system having functionality up to and including the 3rd generation. In a future post I will outline what features I think will mark the move to the 4th generation of blogging-centric social software platforms.
In each of the three classes, I will present a short amount of discussion and produce a simplified table explaining who belongs to that class, what they consider desirable and what they consider undesirable.
These make up the bulk of the participants in any blog platform. If users are users are unhappy with the software, it has failed its first purpose: to make it easy to publish, find and remark upon information.
|Authors & Editors||Visitors||Commenters||Site Administrators|
|Who Are They?||These people provide the “primary” content for the site. They write the articles, style them using website tools and often edit them for style or site-specific reasons. Sites might have only one author-editor, or many author-editors, or separate persons for the author and editor roles.||Visitors are generally people who simply read along with the site. This category is essentially composed of “lurkers” — people who consume website content but do not contribute their own. Users who read via RSS feeds and email are included in this category. Also included in this category are people who visit only for a single item — people who came via a search engine query or from a social bookmarking service like Reddit, Digg or Del.icio.us.||In third generation software, the Commenter is a person who leaves a remark attached to the primary content. Most commenters are “regulars”, people who have contributed comments more than once and who keep returning to the site. Authors & Editors often form a subset of Commenters. Note that this participant is distinguished from the Visitor.||Administrators often emerge from the pool of Authors & Editors. They enjoy a higher level of capability than any other class of user. However they also become a magnet for any and all problems with a site. They are happiest when a site is fast, featuresome and reliable in spite of load. Because of the many-layered nature of blog software, there may be several categories of Administrator: from those who have Administrative rights within the blog software itself, to those having some access to other parts of the software stack (such as MySQL accounts), through to those having total control over all aspects of a particular virtual or physical system (“root access”). They are considered jointly.|
|Objectives||To draft, publish and edit primary material as easily as possible; To follow responses to their material; To have their material highly available.||To read primary material as quickly as possible, in any conforming medium, with highest-possible availability.||To publish comments as easily as possible; To follow responses to their comments.||To have assured high-availability; Assured performance; To have simple and highly automated management of the site|
|What’s good about Gen 3.||Third-generation software makes it easy to work in two modes. The first mode is a web interface supplied directly by the blog software package itself. The second mode is exposing a programming API which can be used by third-party clients such as MarsEdit or Windows Live Writer. These options often simplify writing and editing by auto-generating HTML and presenting a “rich text” drafting environment.||Third-generation software allows users to receive “pushed” or “pulled” content. Generally the “pull” model — fetching from the webserver — is dominant, but users can also have content “pushed” via email or similar mechanisms. This process is now largely automated. For users coming from third parties, the key is to serve material quickly and to respond well to sudden spikes load. Since most blogs are niche-specific, features which help visitors to find similar or related items are very useful — categories, tags, fulltext search and related-item plugins are improvements on the disconnected facilities of the first and second generations of social software.||Third-generation platforms are generally built around a two-tier structure of authors and commenters. By including comment facilities on primary content items, the barrier-to-entry of comments is lowered. The benefit is that more casual commenters can leave remarks.||The LAMP stack is the widely-installed, well-documented basis of almost all blog software packages. Administrators have many points of control, and each layer adds more levers and dials to adjust. Also, in-package administration is simpler than it used to be, lowering barriers to entry for new Administrators.|
|What sucks about Gen. 3||“Rich text” clients can often generate markup which is incorrect: it may not layout as the author / editor wants it to, or there may be semantic errors (such as incorrectly labelled elements). For those used to crafting HTML by hand, it is usually more difficult, especially since most systems defer to automatically-generated HTML by default. This is most noticeable when third-party HTML is inserted — the perennial WordPress vs YouTube issue, for example.||Blog software is not always written to scale; even when it is, plugins may undo the performance characteristics of the core software. This is most evident when a blog post becomes a front page link on a very popular site like Digg or Slashdot: sudden spikes in load may cripple the site when it is most desired. This is not a phenomenon particular to any generation, though in the first generation Usenet largely avoided these effects by the logical and geographical distribution of items between independent servers.||Commenters are a less-privileged class of user compared to Authors & Editors. In particular they rely entirely on the interface mode provided by the software itself — they cannot use a third party client to comment on a site. This can lead to a fragmented user history when compared to first and second generation platforms; users cannot easily review their own and others’ comments history.||Of course, the problem for Administrators is complexity: each layer of the accepted software stack is powerful and flexible. Powerful enough to do almost anything, flexible enough to be broken, and all of them inter-reliant in such a way that failure or misconfiguration of any one layer disables or cripples the entire site. Essentially it is extremely difficult to establish whether a site is optimally configured; and if it breaks, to diagnose the cause. This property was also true of second generation platforms and to a lesser extent the first generation. Another problem is that several third-generation platforms (esp. WordPress) have poor tools for managing traditional Administrative tasks: upgrades, downgrades, backups and rollbacks, management of third-party plugins and the like.|
Blog software needs functionality and form: it needs system and style. There is a distinguishing line between those who use software and those who modify it. So in developers I have gathered together the authors of the core blogging platform, those who write plugins, and those who provide styles and themes.
Incidentally, pay close attention to the similarity between plugin developers and style developers. The latter already largely enjoy what plugin developers don’t: separated concerns. It is easy to cleanly install and remove styles compared to plugins.
|Core Developers||Plugin Developers||Style / Theme Developers|
|Who Are They?||Core Developers write the foundational software, providing the basic functionality which is assumed to be present by users and third parties. They decide what goes into the core and what is left out. They are responsible for day-to-day coding, bug squashing and release management.||Plugin Developers are an extremely important class: they provide third-party code which integrates with the Core blog software to provide additional functionality. Plugin developers are often a larger, less organised and more diverse pool of developers compared to the Core Developers. In particular, Plugin Developers control their own code and don’t necessarily have a say over the direction of the Core.||Style & Theme developers create templates, stylesheets and graphics which change the appearance of a website when added to a blogging platform. Generally they are experts in browser rendering differences, Cascading Style Sheets and the HTML and XHTML specs.|
|Objectives||Since most Core Developers are working on opensource code, the objective is to enjoy themselves! Objectives would be as varied as people, but in particular it would be to produce software which best meets the objectives of other user classes. Others include learning a new technology and professional development.||The same as for Core Developers, with some additions. In particular: Plugin development should be easy.||The same as for Plugin Developers.|
|What’s good about Gen 3.||It can be deployed very rapidly to any-properly configured LAMP stack. It’s also generally easy to become involved in opensource projects, depending on project structure, because the LAMP stack is so widely documented and understood. It can be fun and challenging to develop on.||Plugins are an accepted feature, mostly because they allow Core Developers to ignore a large set of problems. Instead of having to solve something themselves, they merely provide a framework and leave the work to others. This simplifies the Core, making it easier to develop and debug. It also simplifies arguments are what should and shouldn’t go into the Core software. Currently Plugin developers are given extensive access to the inner workings of most Core platforms, allowing quite radical additions and modifications without having to access the Core sourcecode.||Third generation platforms are a giant step forward from second generation code. Style and layout has been largely separated from underlying code rather than woven through. This makes it possible to create quite radical changes in appearance in a self-contained way. Generally, the markup produced by blogging software conforms to the expectations of style and theme designers.|
|What sucks about Gen. 3||The LAMP stack has substantial complexity, as noted above. Also, projects of any longevity and popularity must contend with the interests of Users and Technical Clients as well as their own desires. The current leading case is the development of WordPress. The core software stipulates PHP4 compatibility due to the slow uptake of PHP5 by hosting services; yet for programmers PHP5 offers substantial advantages over PHP4. In short, the momentum of any given combination of LAMP elements is enormous. Core Developers are often stuck coding around tedious problems that have already been solved elsewhere.||Plugin development is difficult, hard to integrate and poorly documented. Few projects have a mature plugins model; in most cases plugins were not part of the initial design. Plugins are still second-class citizens. Also, plugins can interact in inconsistent or unexpected ways when they are combined. Finally, plugins often compromise the non-functional aspects of the core software. They can open security holes or introduce performance hits, for example.||Sometimes the third generation doesn’t deliver on its promises. WordPress still fails to be Unicode-compliant from end-to-end, for example. Also, there is no agreed “vocabulary” of styling, which can slow the adoption of style patterns from one style/theme to another. HTML5 should reduce this problem somewhat.|
Last of all come people for whom technical considerations are paramount. They do not “use” the software, neither do they modify it. But they do interact with it in some way. In some ways these parties are most important, as they can determine the visibility of a package to the world, and the likelihood it will be installed at all.
|Scripts, Syndicators & Search Engines||Hosts||Downstream Packagers|
|Who Are They?||Most websites these days expose a wide variety of on-demand services and data. Some of this is in the form of HTML ultimately meant for human consumption via a browser. Some of it however is designed for use by automated systems. These include scripts for using third-party systems (“Web Services”), sites which syndicate content (syndicators — including ‘plain jane’ readers like Google Reader and interactive systems like Reddit or Rojo) and links to it and systems which crawl, archive and index it (such as Google, Yahoo, MSN or Ask).||These are companies which physically possess the server and provide power, location and internet connectivity. There is a very wide range of hosts, from cheap shared hosts through Virtual Private Servers to colocation facilities. Often host staff will also be Administrators, though generally only indirectly through their control of the total facilities of their company.||Downstream packagers are projects or companies who combine the software with other software into a simple-to-install unit. It can include whole-of-system distributions like Debian, Ubuntu, FreeBSD, Red Hat etc; or “web panels” such as Cpanel and Plesk, or other whole-stack packages like XAMPP.|
|Objectives||Simple interfaces; High availability; Well-documented functionality.||Simple administration; Easy load-balancing; Low support costs.||Easy modification of “physical” layout of software; Few software privileges required.|
|What’s good about Gen 3.||In terms of accessibility to automated third-party agents, third generation code leaves previous systems for dead. In particular there has been a move towards providing APIs for most systems, including standard APIs presented by independently developed systems. The wide availability of common APIs greatly improves the ability of third party systems to add value.||Because most blogging platforms are built on the LAMP stack, it’s fairly trivial to integrate them into existing hosting offerings. It is relatively easy to find administrators with experience and knowledge of some or all of the components of the LAMP stack. Also, inhouse software can be used to add value.||The use of the hugely flexible LAMP stack makes the rearrangement of software directories possible — ie modification of the “physical” layout of the disk.|
|What sucks about Gen. 3||Not much, though more could be exposed if the internal security model was more nuanced.||The third generation just doesn’t scale easily. This is problematic due to the aggregating effect of social bookmark sites like Digg, Slashdot, Reddit and others: a niche blog with few visitors may suddenly find itself at the centre of an intense burst of traffic. Most of the time this upsets the delicate balance of customers and servers. Different hosts deal with it differently, but the core problem remains that present blogging software does not easily load-balance or scale across multiple servers without substantial effort. It can be done, but only with substantial customisation. Certainly not “out of the box”.||The use of the hugely flexible LAMP stack increases the number of issues to be considered by packagers. Permissions for each program need to be considered independently and jointly. Also problematic is that while some packages are forgiving of different physical layouts, they still make particular permissions assumptions. WordPress, for example, assumes write-access to its own document root directory for certain purposes. Some functions won’t work without that functionality, presenting the packager with a need to choose between the options.|
That’s it: a long and tedious document. Importantly, this is only a draft. I’d like to get feedback on what I’ve overlooked, what I’ve missed, and what I have wrong. I will edit the document to reflect feedback, so have at it!