Why this Site?

  • Our Mission:
  • We exist to shine the light of scrutiny into the dark crevices of Wikipedia and its related projects; to examine the corruption there, along with its structural flaws; and to inoculate the unsuspecting public against the torrent of misinformation, defamation, and general nonsense that issues forth from one of the world’s most frequently visited websites, the “encyclopedia that anyone can edit.”
  • How you can participate:
  •  Visit the Wikipediocracy Forum, a candid exchange of views between Wikipedia editors, administrators, critics, proponents, and the general public.
  • 'Like' our Wikipediocracy page on Facebook.
  •  Follow Wikipediocracy on Twitter!

Press Releases

  • Please click here for recent Wikipediocracy press releases.

The dream that died: Erik Möller and the WMF’s decade-long struggle for the perfect discussion system


By Scott Martin. Scott began editing the English Wikipedia in November 2002, and became an administrator in September 2007. He was so disgusted with its management at the time of writing this piece that he resigned his administrator status to take an indefinite break from editing.




The Wikimedia Foundation (WMF) has, in the last few years, embarked upon a number of major engineering projects intended to modernize aspects of its increasingly dated user interface, with the aim of attracting new participants to the ailing encyclopedia project. Referred to internally by the WMF as “Editor Engagement”, these have so far included VisualEditor, a “what you see is what you get” text editor, and Media Viewer. Both were foisted upon a largely unwilling audience of volunteer editors in an extremely unfinished and bug-laden state, leading to large amounts of discord and the generation of any amount of bad will towards the WMF’s “rock star” developers. The latest addition to the WMF’s hall of software fame is Flow, which looks to replace the complex — yet, to most editors of the WMF’s projects, familiar — method for editors to discuss changes in Wikipedia articles. The WMF plans to supersede the old, familiar method, “wiki text” editing of “talk pages”, with a threaded discussion system more akin to that seen in web forums, or the comments section on blogs and news sites. This decision has been no stranger to controversy, attracting much opprobrium from established editors who both see the existing system as good enough to get things done, and have no confidence in the WMF’s programmers after the disastrous experiences of earlier “flagship” projects.

Flow, however, is not the first time that the WMF has embarked on this particular road. For that, we have to look at the history of a much, much earlier project: LiquidThreads (“LQT”). LiquidThreads was a failed attempt to develop a threaded discussion system for MediaWiki, begun in 2004 and eventually abandoned in 2012 in favor of Flow. As with most topics in Wikipedia’s history, no official and comprehensive record exists; instead, a timeline must be pieced together from scattered fragments — engineering news items, bug reports, posts to newsgroups and mailing lists, and public logs of developer IRC channels. By doing so, revealed is a ten-year-long story of the prolonged, lurching, and abortive development of a software project — one man’s quest to bring his personal dream to reality while grinding his way up the ranks of the Wikimedia Foundation.

Context, conception and creation

The idea of a threaded discussion system for MediaWiki has as its earliest recorded occurrence the page Enhancing talk pages on Meta-Wiki (the WMF’s international cross-project coordination and discussion site), created in March 2004 by Antoine Musso (“Hassar” from the French Wikipedia). Musso noted some of the difficulties involved in correctly participating in talk page discussions, proposing “If the mediawiki offer a simple reply button under each replies, it will save readers a lot of comprehension work.” However, nothing came of the suggestion. (He’s still waiting.)

That summer, the notion of threaded discussion arose again. In July 2004, members of WikiProject Aircraft had come to an agreement that talk pages weren’t good enough for their needs, and quickly set up their own external forum. The move attracted controversy, sparking a discussion at the village pump not long after in which Erik Möller (“Eloquence”), at the time the WMF’s “content partnership coordinator”, strongly condemned the idea, stating that “when properly handled, [talk pages] are superior to a forum.”

I’ve been thinking in the last few weeks about a good way to combine the advantages of talk pages and discussion forums into a truly revolutionary new system… which I have dubbed “LiquidThreads” for now.

Erik Möller, post to Wikitech list, 27 September 2004

The discussion had clearly given Möller food for thought. A month later, during a discussion on the Wikitech mailing list about “MediaWiki 2.0”, a proposed next generation of the wiki engine, Möller described his ideas for a new way of hosting discussions that would uniquely address the needs of wiki editors. He followed that a couple of weeks later by posting the first draft of a design proposal for his new system. The idea attracted a smattering of discussion, but little else.

Eighteen months later, in late April 2006, MediaWiki developer Gregory Szorc (“IndyGreg”) added an idea to the list of potential project proposals for that year’s “Google Summer of Code” — the search giant’s yearly program of awarding grants to programming students. A few days later David McCabe, an 18-year-old freshman at Clark College in Vancouver, WA, proposed to build LiquidThreads. The following month, his proposal was accepted. He began work on implementing the system, describing the work he was doing in his project blog, until concluding his summer’s work. In late August he left LiquidThreads with the WMF, in an incomplete state.

First installation

Möller was by this point running a company, MyOO (”Make your Own Organization”), providing server space and technical support for people operating wikis (including future Wikia superstar Memory Alpha). That same April, MyOO began hosting a project called WikiEducator, launched and funded by the intergovernmental education organization Commonwealth of Learning (COL).

In January of 2007, participants in a WikiEducator tutorial had complained of difficulties in using a wiki for discussion. Möller had at this point become the CTO of Stichting Open Progress, a Dutch not-for-profit organization “[that aims] to develop both Open Source/Free Software and Open Content/Free Content projects”. The organization also had Gerard Meijssen (“GerardM”) as its director.

It’s under active development with funding from COL.org and Wikia.com. … There’s still lots of work to do but we’re making
good progress.

Erik Möller, post to Mediawiki-l, 14 August 2007

On 19 February 2007, on WikiEducator, Möller proposed the further development of LiquidThreads as a threaded discussion system, suggesting a budget of €7500. A funding agreement was made with COL two days later. Stichting Open Progress brought David McCabe back into the fold, and by June 2007 were ready for WikiEducator to try out LiquidThreads.

A short period of further development elapsed, with further funding acquired from Wikia until the end of the year; and Stichting Open Progress acting as project managers. LiquidThreads was eventually installed on WikiEducator in October 2007 — its first real-world site installation.

Community dissatisfaction

LQT is of strategic interest to the Wikimedia Foundation: having a user-friendly discussion system — not necessarily to replace talk pages, but at least to have in place in highly public-facing areas such as the WMF website — could really help us.

Erik Möller, “LQT 2.0” WikiEducator list post, 17 July 2008

Development of LiquidThreads seems to have dried up at the beginning of 2008 following the conclusion of McCabe’s funding period. However, in June, Möller — who had become Deputy Director of the Wikimedia Foundation in January — sent a message to the WikiEducator list titled “LQT 2.0”. In it, he informed the WikiEducators that McCabe had got in touch, saying he could work long-term on the project for the Foundation. So, would they provide feedback and information on things that needed to be done? What he didn’t expect, however, was that his post would open the floodgates for a torrent of complaints and requests for not only user acceptance tests, but an option to selectively disable LiquidThreads. The comments were stinging. “LQT is probably the single main issue/reason I’m currently using Wikiversity over Wikieducator,” complained one poster. “I see nothing wrong with innovation — bring it on. But there might also be something to be said for KISS — and elegance… if I can’t easily converse on an educational wiki, for me, there is not much point,” worried another.

The repeated requests for a per-page “toggle” for LiquidThreads, or its demise entirely, were met first by Möller with a reassurance of it being a community decision (“If WikEd wants to implement a per-page toggle or turn off LQT entirely, that is obviously its prerogative.”), but later the same day he watered the commitment down, effectively informing the mailing list posters that their consensus was insufficient (“What I’d propose is a community review with a firm deadline, say, December 1 2008 as a start of the review process, and a decision made by January 1 2009.”), and that they were not the right kind of users to be making the decision (“I would advise… trying to identify WE community members who potentially bring different perspectives to the table, e.g. a more newbie-focused perspective vs. that of the routine user…”). Anyone who’s been following the interactions of the WMF’s developers with the users of their new features in the last few years may well be experiencing some déjà vu at this point.

To be honest after my eighteen years in software development I have never worked with someone who spends more time defending a position (and thinking they are right) than they do listening to the genuine frustrations and requests from a user community.

Peter Rawsthorne, WikiEducator thread, 25 September 2008

Another mailing list thread began soon after with a similar tone, characterized by multiple serious user complaints (“i have barely touched a talk page since they were implemented. a real shame.”) and stonewalling from Möller (“I have argued before, and continue to argue, for a period of time in which we improve the system based on user feedback, and _then_ a period of evaluation in which we consider the options for WE. Turning off the system now is disruptive, and makes it in fact harder to address the concerns and objections that have been voiced.”). Frustrated by this apparent refusal to take their concerns seriously, WikiEducator users subsequently began to take matters into their own hands, with one “setting up sub pages as pseudo talk pages to get around this problem”. However, Möller’s position was backed by the project’s founder, and so the status quo remained unchanged.

Kind of telling wouldn’t you say, that so much of the discussion re: LQT takes place on the ‘mailing list’ rather than on the wiki, so that rather than being organized around a central page on LQT they’re lost in inboxes all over the world. The proliferation of such lists coincides with the implementation of LQT.

Brent Simpson, WikiEducator thread, 25 September 2008

The following month, the debate was reignited in a discussion thread on WikiEducator, where concerns were raised both about Möller’s dismissive approach towards WikiEducator users requesting changes that he disagreed with, and the inconsistent and confusing way that he defined his role in relation to the site and development of the software. The discussion spilled back onto the “LQT 2.0” mailing list thread, where “a formal request to turn off Liquid Threads” was posted.

Despite all of this, nothing changed. Möller’s commitments with the Wikimedia Foundation drew him, and his developers, away from WikiEducator; and LiquidThreads remains there to the current day, with the hybrid talk page hack still visible in places — wedged on version 1, due to the older version of MediaWiki that the site runs. A recent page on the site optimistically suggests that someone could “reverse engineer LiquidThreads (LQT) version 1 and provide a migration path to LQT2 and/or Flow”; in 2011, the same page’s author took a stab at it for all of half an hour before giving up. That’s hardly surprising; in June 2014 a WMF engineer admitted that they won’t be attempting to extract the content of LiquidThreads discussions, but merely archive them instead to exist in frozen form away from a new Flow installation. The future path of discussion formats on WikiEducator remains unclear, apart from on one point — whatever help eventually comes, it won’t be from the engineers of the Wikimedia Foundation.

No such uncertainty, however, is necessary for the users of translatewiki.net, a MediaWiki-based tool for translating parts of the interface of different pieces of software into other languages, including MediaWiki itself. Although translatewiki.net itself is “not part of the Wikimedia Foundation projects… [i]t is run by Nike and Siebrand, who both are MediaWiki developers”. The WMF’s page about its Language Engineering Team notes that “Many of the key people of translatewiki.net make up the Language Engineering team” — Such as its founder, Niklas Laxström, who in April 2012 would be praised at length in the Wikimedia blog by former Stichting Open Progress chief Gerard Meijssen, now an “internationalization / localization outreach consultant” for the WMF. (Stichting Open Progress itself was liquidated towards the end of the year.) Unsurprisingly, Meijssen has been cheerleading loudly for Flow in recent mailing list discussions. The operators of translatewiki.net have also been in direct conversation with the WMF’s Product Manager for Flow, Danny Horn, who noted in June that “Last month, Siebrand told me that he was interested in moving translatewiki’s discussions from Liquid Threads to Flow, when Flow was ready for it. That’s the only conversation we’ve had about it so far. There will be a lot of details to figure out and work on, for translatewiki and any other possible deployment plans.” A far warmer treatment than that received by the unfortunate burghers of WikiEducator; but who can be surprised, given the cosy relationship between the supposedly non-WMF translatewiki.net project and the WMF?

Second era

Andrew Garrett (“Werdna”) assumed primary programming duties on the project in 2009. In Q3 2010, it was classified as “WMF-driven dev staff + extended staff work”, with an engineering report noting that Alolita Sharma (“Alolitas”), the Director of Features Engineering, was managing the project; and that the WMF engineers were “planning for an initial phase of deployment in the first half of next year.” That same month, one of the programming team, Brandon Harris (“Jorm”), came under fire for apparently trying to “own” the project and take it away from community input.

A status timeline for LiquidThreads was set up shortly thereafter, and was maintained for a year afterwards. It provides a window into the problems that emerged during the next phase of the project’s development, with an optimistic schedule being plagued by repeated lack of resources.

Being the lead developer for LiquidThreads, my priority remains to focus on the re-engineering work that we are doing, so that we can start piloting the new version as soon as possible (hopefully by the end of March).

Accordingly, it is our decision that further pilot deployment of LiquidThreads instances is placed on hold for the time being. LiquidThreads re-engineering will hopefully be finished in two to three months, and at that point we will be very pleased to roll out pilots to additional wikis.

Andrew Garrett, 21 January 2011, bug 119699 comment #10

In January 2011, a proposal for major reengineering of LiquidThreads was made: ”LiquidThreads 3.0”. This followed the development team’s damning conclusions about the existing version — that it had a fatally flawed database design which relied on using wiki pages for storage, leading to a number of data corruption bugs, a haphazard revision control system, and confused internal code structure. An unusual scan of a hand-annotated printout shows Garrett’s notions for the large-scale modifications that would be necessary to rebuild the system as LiquidThreads 3.0; in its current state, LiquidThreads could simply go no further.

[04:30:40] <Shirley> The whole LQT architecture was/is pretty braindead, but I thought we were stuck with it.
[04:31:29] <Shirley> Is LQT going to be forked?
[04:33:20] <werdna> no
[04:33:30] <werdna> it's just a major refactor
[04:34:36] <werdna> things are being moved around, the schema is changing
[04:37:48] <werdna> Shirley: basically we found that LQT's existing architecture/codebase had been pushed to its limit

#wikimedia-dev IRC channel, 22 January 2011

Garrett’s development task list for 3.0 in March 2011 notes that “[Planning was] done by Brandon and Andrew, in consultation with much of the Wikimedia tech team.” A later revision of the notes added a telling proviso, giving a window into the amount of resources that the WMF’s developer management thought would be sufficient to make LiquidThreads fit for purpose.

Timelines are approximate, possibly underestimated, and assume that Andrew Garrett is the only developer assigned to this project. They take into account the following probable disruptions:

  • Andrew is working on another large project at Cancer Council Australia, which concludes in late June to mid July.
  • Andrew is a university student, and his general availability will be limited throughout June due to examinations.

LiquidThreads 3.0/Phase 1 on MediaWiki

Withering on the vine

LQT is like the Duke Nukem Forever of wiki software.

“Equazcion”, Village Pump thread, 19 July 2011

That summer, a suggestion at the Village Pump that LiquidThreads should be enabled was met with notable resistance, before eventually being closed as moot because no installation of LiquidThreads 2.0 would take place while 3.0 was under development.

We don’t see how LiquidThreads could ever become a reliable system, so we will just pretend it never existed. I’m personally very sorry and wish to apologize if my early enthusiasm for LT gave anybody else the false impression that this could be a working solution.

Lars Aronsson, post to the Wikitech list, 11 October 2011

From June-August 2011, development on LiquidThreads was put on hold in favor of MoodBar. MoodBar was another doomed WMF project; deployed to very little practical effect, it survived for almost two years before being taken out back and put out of its misery. The curt epitaph Harris wrote for it doesn’t suggest a well-attended funeral: ”2013: February 5: Undeployed from the English Wikipedia”.

In October 2011, Lars Aronsson from the Swedish Wikisource community announced bitterly that they were giving up on LiquidThreads. This was a drastic turnaround; only nine months earlier, he had recorded that “Swedish Wikisource already uses LQT and is perfectly happy, even though it took 4 months between request and activation.”

One of the replies came from a TranslateWiki user, who noted that they “too have long ago stopped filing bug reports against LQT, because they just don’t get any attention. We have been waiting for the rewrite to finish for so long I can’t remember anymore, at least six months.”

Pass the parcel

Whether any active management of the project actually came from Sharma is hard for an external observer to discern. “Nothing seems to have happened on Liquid threads in the last 5 Month — can you provide us with some information?” asked worried editor Dr. Gregor Hagedorn on her talk page in April 2012, without receiving any reply. The “five months” probably refers to the last time that LiquidThreads was ever mentioned in an engineering report, in October 2011.

What Dr. Hagedorn didn’t understand was that the best way to get information on a WMF project is to go straight to its developer. That was what another user had figured out the month before, eliciting a blunt comment from Garrett: “Further deployments of LiquidThreads are indefinitely on hold because we don’t have the resources to support it.” Garrett’s colleague Harris shared that opinion, although he was explicit about to where the blame lay for the resource shortage.

[21:15:52] <vvv> What's current status of LQT 3?
[21:16:11] <jorm> "indefinate hold"
[21:16:26] <vvv> jorm: any perspectives of revival?
[21:16:34] <jorm> not in the current term, no.
[21:16:39] <vvv>  🙁
[21:16:43] <vvv> Vaporthreads
[21:16:55] <jorm> andrew built some stuff and checked it in but i don't think it's been deployed to a test server.
[21:16:56] <jorm> well.
[21:17:02] <jorm> whose fault is that?
[21:17:07] <vvv> I have no idea
[21:17:28] <jorm> everytime anyone mentions the idea of spending resources on it, a bunch of people get all up in arms
about it.
[21:17:49] <Reedy> Who needs to communicate anyway?
[21:18:19] <jorm> if every time we're met with a "over my dead body" response, then you can't fault the foundation for
downgrading its importance.
[21:18:40] <jorm> there are other things in the works, though.
[21:18:45] <jorm> search mw.org for "Flow"
[21:22:18] <vvv> jorm: are there even sketches of that thing?
[21:23:13] <jorm> yes and no. preliminary stuff, nothing to look at yet.
[21:23:23] <jorm> you know me; i'll have stuff up as soon as humanly possible.

#wikimedia-dev IRC channel, 28 May 2012


In August 2012, English Wikipedia editor “MZMcBride” wrote an op-ed for the Signpost, the site’s internal project news magazine, bashing bad software development at the WMF.

I would dearly love to build out Liquid Threads into the type of system that I think it could (and should) become. But we just don’t have the manpower to do it, especially given the extreme pushback from the global editor community.

Brandon Harris, Discussion at MediaWiki, 25 July 2012


Sharma’s tenure overseeing the project came to an end in July 2012, and it was passed to James Forrester (“Jdforrester”). However, Forrester seemed to realize that the parcel he had just been passed was radioactive, perhaps taking into account the firmly-expressed opinions of his colleague Harris, and the following month management of the project was dumped into the lap of Terry Chay (“Tychay”), who had become the new Director of Features Engineering in February.



… it’s unclear how much the Foundation has learned from its past mistakes. The lack of follow-through with its software development and the quick abandonment of any difficult project (FlaggedRevs, LiquidThreads, etc.) is troubling. The same people who worked on some of these past duds are now being brought in to lay the groundwork for other redesigned and re-engineered projects. We’re seeing the same worrying trend of bringing in a contractor, who starts the development work, then leaves before it’s finished. The code then rots.

In a mailing list discussion about the op-ed, WMF staffer Ryan Lane added:

LiquidThreads was also originally community designed. The maintainer added every feature under the sun that the community requested, which led it to become a bloated and difficult to maintain piece of software.

Could that op-ed perhaps have stemmed from this discussion on MediaWiki.org a month before, “Is [Flow] the new LiquidThreads?”, also started by MZMcBride? An extensive series of opinions on the question were presented by Terry Chay:

The lesson learned from LQT is that it was too aggressive in what it supported and was supposed to do. … I don’t think the goals of messaging can replace LQT. In determining editor engagement and features goals, it was clearly obvious that user-user messaging is broken so a project was put in 2012-13 goals to address that. This has been named “Flow” and according to planning will not be worked on directly until early 2013…

There are no formal resources for LQT development in this year’s planning (there are no formal resources on Flow for half the fiscal year). However, the same people involved with Flow are the ones who have worked on LQT which means that there might be some design guidance and bug prioritization for what needs to be done here and it can be kept up-to-date. (I’ve tried to give the developer the freedom to update LQT code under the auspices of working on Echo and Flow.). …

It’s my hope that by placing the same people on both Flow and LQT, the developer of LQT will get some guidance on the the LQT bugs/features that should be dealt with. … The LQT developer is left alone without any support from community feedback, infrastructure/ops, and product design and development when it comes to LQT and LQT3 (which was a deferred project before I even joined the WMF). In the past, we’ve found that when left without support, projects have a tendency to runaway and/or never see the light of day. The WMF plans to not repeat these past mistakes in features (PendingChanges, LQT, LQT3) by providing that support on formal features going forward (AFTv5, Page_Triage, Article_Creation_Workflow, and the VisualEditor being examples of this new approach which will be applied to Flow and Echo this fiscal year). …

Messaging was determined as a “must have” by Product’s 3-year plan to deal with Editor Engagement. Flow came out from that, not a determination to keep or abandon LQT. For the 2012-13 planning/goals, we added Flow at the last minute which is much more aggressive planning that normal (I felt we can safely do Notifications & Global Profile. The latter was pushed out and Flow was added.)

The worry is to continue or repurpose LQT to solve messaging goal would jeopardize actually accomplish that goal to within the aggressive timeline. I felt that it was more likely to accomplish some sort of messaging this fiscal year with the option of backporting to LQT or gradual improvement of Flow would be better than to try to shoehorn LQT and its baggage into the messaging problem.

All of the foregoing history in this post may now be compared to the narrative presented by Erik Möller in a post to the Wikimedia-l mailing list in September 2014. In it, he makes no mention that the developer who “did a good initial job [but it] had many known issues” was an 18-year-old college freshman on summer vacation, and when mentioning WikiEducator, omits any detail of the fiasco into which his involvement with that project became.

To Utopia and beyond

In the future, Flow will grow to encompass all manner of tools, including:

  • A Watchlist module
  • A Wikiprojects module
  • Further Discussion modules to cover additional use cases (like !voting, noticeboards, the Teahouse, reference desks, article discussions, and so forth)…

Brandon Harris, Flow page on MediaWiki, May 2013

As described by Chay, by 2012 the WMF’s engineers had realized that LiquidThreads was dead in the water. Their solution was to begin again, learning from the mistakes made in the earlier project and producing a stronger, more refined implementation of Möller’s vision. That implementation was to be the Flow project.

Flow, as it exists today, is a rejection of a far grander vision once put forward by Brandon Harris. At its initial description in April 2012, Flow had been merely “a new interface for user-to-user communication”. By March 2013, however, Harris’ notion of it had ballooned: becoming a colossal Rube Goldberg machine that would encapsulate a variety of common “workflows” that currently utilize talk pages. These would be anything from welcoming new users to requesting being unblocked, among many, many others. By May, his plan had become even more grandiose, declaring an intention to swallow up swathes of popular Wikipedia discussion areas.

Harris’ Ozymandian dream persisted until September 2013, when WMF product manager Maryana Pinchuk, less than a month after joining the Flow team, took an axe to it. In a single edit, she reduced Flow to once again being a simple replacement for talk pages, accompanying the change with only the laconic edit summary “prune for focus”. No public record seems to exist of the team discussions that led to this move, but it hints strongly at the application of a managerial clue-by-four.

Carry on regardless

By autumn 2013, working demonstrations of Flow had become available, and critical feedback was coming in thick and fast. Almost every aspect of the design, usability and even basic concept of Flow “boards” was met with disbelief, disapproval, or derision to some degree. Many of these may be seen at Talk:Flow on the MediaWiki site, which itself was chosen as a Flow demonstration area, and the talk page of Flow’s Design FAQ. Getting the engineers to listen to feedback about their design choices seemed to be tremendously difficult: an early decision regarding “the right amount of whitespace” was universally condemned as excessive. The objections were met with continuous stonewalling. The volume of criticism was so great that in October Pinchuk wrote a document describing “community engagement” for the Flow team. It was barely mentioned anywhere, and forgotten almost instantly, with no sign that her team had even read it at all.


Media Viewer in the middle of loading an image

In summer 2014, the WMF inflamed editor temperaments yet further with a bungled and controversial rollout of their incomplete “Media Viewer” tool. The editing community, already made wary and defensive by the long-running and painful saga of WMF Engineering’s attempts to build another flagship feature, the “VisualEditor” WYSIWYG editing tool, found itself in direct conflict with Möller. Despite large numbers of editors sounding the alarm over bugs and poor design in a tool that was clearly unfit for primetime, and a number of wikis demonstrating strong local consensus that they did not wish to have the tool forced upon them, Möller was absolutely insistent that it would be rolled out. It was. This led administrators on some wikis to revolt against the imposition, editing a low-level part of their site code to disable the tool from functioning, even though it was present on the system.

For more on WMF Engineering’s attempts to build and roll out major new software features, see our blog posts Media Viewer fails the grade, and Wikipedia’s new editing software gets failing grade.

Such disobedience did not sit well with Möller. However, as the changes had been made by local administrators, there was no way to change them back and prevent them from being made again — even if the page were to be “protected” and the administrator in question blocked, they could simply unblock themselves and edit regardless of the page protection. A “wheel war”, in editors’ jargon, of the worst kind. As a result, Möller took the unprecedented step of having a new level of page protection implemented by the engineers — “Superprotect”, available only to WMF staff members. Site elements with Superprotect set would not be editable by any normal user, even with the highest level of community-granted privileges. Unsurprisingly, this move was not received well by Wikipedia users. A month later, a petition to the WMF requesting they remove the Superprotect feature and formally allow individual wiki communities to decide when or how they want new features to be applied had garnered an equally unprecedented 897 signatures. (At the time of writing, the count stands at 1,042.) Despite the astonishing strength of opinion on display, Möller and the WMF did not budge in their position, although in subsequent months their responsiveness to editor feedback regarding the feature increased noticeably.


Public discussion regarding Flow has dropped off dramatically since the middle of last year. In order to look to the future, interested observers have had to read between the lines, noticing things such as the addition of “Done” markers to the project roadmap ceasing in the July-September 2014 quarter (an earlier release plan by Pinchuk has sat unmodified since March 2014), and the recent reduction in the Flow team’s size from ten staff to six.

The eagle-eyed follower of WMF developments will find the mention of September 2014 familiar, for one key reason: that month, Möller’s role within the organization changed. While retaining the title of Deputy Director of the Wikimedia Foundation, he ceased being the VP of Engineering, moving — or being moved — instead to the role of VP of Product and Strategy, at a distinct remove from areas of engineering. His replacement was brought in by the Executive Director, Lila Tretikov, who had taken the reins at the WMF in June. The new VP of Engineering, Damon Sicore, was an outside hire, with a track record including six years spent at the Mozilla Foundation. This appointment stands in sharp contrast to Möller’s recommendation to Tretikov’s predecessor Sue Gardner, described in a mailing list post in 2012, that his replacement in the role should be an internal candidate. Those reading the tea leaves will probably do well to see this as a demonstration of Tretikov’s new approach to the Foundation’s management.

Möller’s move was accompanied in short order by the departure from the WMF of another of the key Flow players — Brandon Harris, who vacated the premises in November. No official announcement was made of his leaving, but he posted about it on Facebook. In the discussion thread that followed, he stated candidly:

…one of the reasons I left EA to join the Foundation was, ostensibly, so that I could get back to making games. And I didn’t do any of that.

Harris’s role at Electronic Arts (EA) had been that of building business applications for their HR department, but in his spare time he had been operating a browser-based online roleplaying game. That eventually had to shut down after he ran out of money to operate it, and because his EA contract was restrictive. Six months later, he had quit EA and joined the Wikimedia Foundation.

In 2011, visitors to WMF wikis were presented with statements from various employees of the organization as part of the fundraising drive for the year. In his statement, Harris told readers:

I work at the Wikimedia Foundation because everything in my soul tells me it’s the right thing to do. I’ve worked at huge tech companies, doing some job to build some crappy thing that’s designed to steal money from some kid who doesn’t know it. … When you give to Wikipedia, you’re supporting free knowledge around the world. You’re not only leaving a legacy for your children and for their children, you’re elevating people around the world…

For the benefit of your children and their children, and those people around the world, to the right is a photograph posted by Harris in a subsequent comment to the Facebook thread. It shows all the boarding passes from the numerous national and international flights that the WMF provided him with to their events, at readers’ expense. Bon voyage, Brandon.

Four years' worth of airline boarding passes bought for Brandon Harris by the WMF using readers' money

“Here’s four years of boarding passes.” — Brandon Harris, Facebook post, 21 November 2014

The kiss of death

The movement of staff away from the lurching Flow project, however, was instantly overshadowed this month as an omen of its future. In a little-noticed post on her Meta user talk page, responding to a user query, Tretikov offered her assessment:

Talk pages serve MANY diverse use cases; they have much of the power of a programing language. A single prescriptive/pre-configured tool such as Flow cannot (and probably should not) address them all.

Flow is a communication tool similar to many available on the web and for many sites would be great. It does not today address collaboration and complex wiki-usecases. As such it is not ready for “prime time” for us.

Flow in the current form is not a replacement for the current Talk pages. If I were to draw a venn diagram of Flow vs. Talk vs. Talk Prime (something super-user would seem to want Talk to become), the overlap would be very modest.

It is not clear if Flow could ever be/become a replacement for Talk in its current concept. We are investigating if this paradigm is too fundamentally different, or if we need different tools for different jobs. Flow may be useful as just a communication tool. This is to be validated. The team is doing some prototype testing.

Beginner users do need simpler on-boarding process. We need to solve for this on-ramp experience (both to teach new wikipedians and to no burden experienced ones). But we also need to keep in mind our super-editors that know and understand the powerful Talk system. We need to find a way to not break the experience for the super-editors while building a simpler one for newcomers.

Finally and most importantly we need to further improve how we conceptualize and build complex features like this one. More early validation and understanding our audience is a must.

Sorry this is not a “final” assessment. But I would be curious to hear your reactions. Thanks. LilaTretikov (WMF) (talk) 23:10, 5 January 2015 (UTC)

Over the years of the tortuous history of Möller’s “truly revolutionary new system” creeping towards fruition, his views regarding its utility and necessity had hardened. In the “LQT 2.0” post in 2008, he had seen it as “not necessarily… replac[ing] talk pages”. By 2014, in the same mailing list post as his history of LiquidThreads, his position had become that “based on… long term functional and architectural considerations, I think [such] a system… is ultimately necessary”.

Tretikov’s comment that “Flow in the current form is not a replacement for the current Talk pages” flies completely in the face of that position. In the opinion of this writer, it’s a nail in the coffin of Möller’s vision for the future of discussion on the Wikimedia Foundation’s projects.

This article was edited on the 11th of February to correct the mention of “10 coders” on the Flow team to “10 staff”. Thanks to WMF employee Nick Williams (“Quiddity”) for noticing the error.

Image credits: Flickr/RL Fantasy Design Studio, Wikimedia (licensed under Creative Commons Attribution 2.0 Generic), Facebook

14 comments to The dream that died: Erik Möller and the WMF’s decade-long struggle for the perfect discussion system

  • ericbarbour

    “Flow is a communication tool similar to many available on the web and for many sites would be great. It does not today address collaboration and complex wiki-usecases. As such it is not ready for “prime time” for us.”

    But your organization just spent seven years and millions of dollars developing it.

    Don’t like the results? Then fire someone, madame.

    • pasky

      Well, Brandon Harris has left, didn’t he? And maybe some of the programmers did too, which we probably have no way of knowing (but the team did get smaller).

      Even though of course the article is unopiniated and some of its comments don’t seem fair to me – frankly, this really does seem like quite an absurd endeavor, and woeful inexperience in software design and project management. IMO the 20% effort (or much less) that would fix the 80% (or much more) of UI issues would be simply automating the mediawiki markup editing on talk pages! Just add “add new topic” button to the page, “reply” link after each ~~~~ that’ll show up a textarea for your comment and upon submission simply edit the wiki source automatically, adding your comment. New users don’t have to learn all the syntax rules and discussion can proceed quickly and with much smaller amount of editing races. Power users can still just edit the page when it’s needed in the very long tail of uncommon cases.

      Handling all the corner cases, shouldn’t take than a day to develop to a single Mediawiki developer. With some design work and a lot of testing, less than a week. Ironed out for a month or two during live beta testing and there you go. I must be missing something? What?

      You’re fixing the most pressing problem and meanwhile your other 5.75 developers can continue building the Flow castle in the sky.

  • Bureaucrat

    The one thing I can add to this bizarre failure is that Wikipedia has become a bureaucratic monster

  • Tim Davenport/Carrite/RfB

    Nice piece, Hex…

  • y’know… sometimes people don’t realise that if software does the job, it really doesn’t need changing [excluding maintaining and security patches of course]. i am kinda strangely proud of the cast-iron star i received a few years ago. i got it for beating ideas into submission at one of the first public wikipedia strategy discussions. many of the ideas i took a very large baseball bat to included extending the wikipedia editing to globally and unreservedly permit java or other programming languages to be interpreted by either the server (or, worse, the display client – usually the browser). most of these ideas i had to point out would completely destroy the “reach” of wikipedia by making the encyclopaedia too complex to run (offline or on low-cost hardware are two examples).

    the problem with wading in with a baseball bat to squash ideas – even when done carefully and with sound logical reasoning and entirely devoid of emotion or any kind of accusation – is that in wikipedia you become a target of distrust, through a process that can escalate *entirely without your knowledge*. it’s a bit like being tried by a secret kangaroo court, where the judges know – and apply – the laws *without* consulting or educating you, continuing a process that often, especially because they are human and fallible, was based on mistrust (in direct violation of the wikipedia charter) or plain misunderstanding.

    so whilst it would appear that nobody has really stood up to moller, i have to say that after experiencing several instances of “wikipedia secret trials” i am honestly not surprised to learn that it’s not something that anyone else is doing, either.

    all i can say is: welcome to one of the worst aspects of foundations – not that pathological profit-maximising companies are better. i’d like to be able to recommend that the wikipedia foundation convert to being a CIC, but, like all the other voices that have been ignored i am just one more in the sea of noise…

  • Given up on Wikipedia

    Wikipedia’s community has become toxic, hostile to outsiders, and has developed such an inertia as to make positive change nearly impossible to accomplish. Either the foundation needs to step in, begin imposing technical changes based on their merits and consistancy with the core principles of the project rather than the whims of whoever can cry the loudest, or eventually, someone else will step in who can do it better, without all the drama and dead weight.

    IMHO, Fixing MediaWiki (and therefore, the various WMF projects) over the long term would include dumping the current markup, the destruction of the current template system (the current one leads to pages which are so complex that they cannot be safely edited by newcomers, violating “anyone can edit”), and the adoption of various quality of life improvements.

    Frankly, I’m amazed the developers haven’t told the community and WMF to collectively go f*** themselves after the number of hours spent on various inititives which have been aimed at improving the experience for newer editors and then “vetoed” by voval members of the community that secretly want to keep new people out.

  • no

    I actually use an SVN version of Liquidthreads on my own wiki. It works fairly well in its current form.

  • HRIP7

    Note discussion of this article on Slashdot, including comments by Erik Möller.

  • Mike

    There are dozens of perfectly good forum and discussion systems that could be used or adapted for this purpose, why aren’t any of them being used?

    It’s ridiculous in the EXTREME to be reinventing the wheel in terms of a discussion system at this point.

    Everyone involved in this debacle should be shot and then hung and then buried at sea. What a bunch of incompetent time-wasters.

  • For a similarly fascinating story – google ‘Project Xanadu’

  • Oiyarbepsy

    Naturally there is discussion of this on Wikipedia: https://en.wikipedia.org/wiki/Wikipedia_talk:Flow

  • Lucas

    Stumbled here from a slashdot search… Very nice to get some of the peripheral information on what happened with LQT/Flow in one place, thank you. Been waiting patiently for resolution of this need for years now. LQT seemed to have the basic features, but I’ve always been hesitant about setting it up on our intranet mediawiki sites due to it’s inactivity. Had also often wondered what the hell could be taking so long!

    While we’re still in the very early stages of contributor growth in our corporate wiki projects, it’s interesting to consider that someday even they could evolve into bureaucratic and hostile environments. While it’s an unfortunate fate for any project, I take some small solace in the idea that this signifies some sort of milestone. That a collaboration with such problems has matured. That there is something there, where before there was so little.

  • Wikipedian

    It seems that Flow development has been stopped finally. Now the focus is on workflows: