The views expressed in this op-ed are those of the author only; responses and critical commentary are invited in the comments section. The Signpost welcomes proposals for op-eds at our opinion desk.
The Wikimedia Foundation sometimes proposes new features that receive substantive criticism from Wikimedians, yet those criticisms may be dismissed on the basis that people are resistant to change—there's an unjustified view that the wikis have been overrun by vested contributors who hate all change. That view misses a lot of key details and insight because there are good reasons that Wikimedians are suspicious of features development, given past and present development of bad software, growing ties with the problematic Wikia, and a growing belief that it is acceptable to experiment on users.
There's a lot of agreement about the major technical pain-points of Wikimedia wikis. Any non-programmer who has interacted with a MediaWiki talk page or tried to edit a marginally complex article can quickly identify problems with the MediaWiki software and its design. Talk pages are horrific. Editing is horrific. Page load time—particularly for logged-in users and particularly for articles with a high number of complex templates—can be horrific. Change is needed; or to put it even more politely, there's a lot of room for improvement.
Agreement aside, we're seeing a disconnect right now between what the Foundation is spending resources on and the issues faced by the community. This misalignment has a number of origins. While many people agree that change is needed, the question is whether the Foundation will deliver these changes.
Past and present projects
Wikimedians are wary because the Foundation has been producing bad software. The bad software can be split into two groupings: older and more bloated, and the newer and less bloated.
FlaggedRevs is an example of the former. After years of delays, it was rebranded at the last minute as "Pending Changes", finally deployed to the English Wikipedia, and was a complete flop. The software was bloated, slow and inflexible, and was marred by poor usability. Ultimately, even its most die-hard fans saw that it was not going to work. Rather than focusing on improving the software, the Foundation dragged its feet and largely ran out the clock on the extension. The hope was presumably that eventually everyone would focus themselves on something other than the BLP problem, a strategy that was successful.
LiquidThreads is another example of older, bloated, bad software. Again, it was developed over years, was finally deployed to a number of smaller wikis, and was a disaster. It had substandard usability and very little support from the Foundation. Eventually it was abandoned, leaving small wikis (and anyone else who had the misfortune of having decided to use it) with absolutely no upgrade path.
New user or not, nobody wants to log in and see this.
On the other hand, people would be thrilled to log in and never have to see this again.
More recently a newer type of bad software has been emerging, less bloated (in the sense of being meant for niche uses rather than general use) and more expensive. This includes MoodBar, ArticleFeedback (in its umpteen versions), and WikiLove. These software come with costs. The first and most prominent is that these features—as childish and valueless as they are—deplete a finite set of resources available for software development. In other words, these endeavors waste human resources. Established editors largely roll their eyes at the features and hope they don't make too much of a mess.
The secondary cost of requiring established users to administer these poorly thought-out and inadequately developed extensions cannot be overlooked. As surprising as it may be, given the years of development ploughed into them, a number of these extensions were deployed without anti-abuse mechanisms. This is unacceptable. Article feedback is a safe haven for spam and other useless noise. WikiLove is more often used by spammers and others who have no idea what it is or why it's there than it is used legitimately.
Some development of bad software is the natural result of the Foundation's growing pains. Not every line of code is going to be magical and work well, especially on first try. But 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.
The newer category of software is part of the Foundation's "Wikiafication" efforts. Most people know Wikia as that family of wikis overrun by advertising, full of low-quality content, and bloated by poorly optimized code, making the site slow and generally unappealing. This has become the Foundation's model to follow, and the long-standing closer relationship with Wikia makes many Wikimedians very cautious.
The for-profit nature of the site aside, Wikia has engaged in a number of poor social and technical practices over the years that have disrupted and harmed its communities. Wikia is a bad model, and the increasingly close collaboration between the Foundation and Wikia on projects and development is cause for concern. That said, learning from Wikia's mistakes in areas such as the development of a visual editor is not a bad idea. The Foundation should look at Wikia as a model of what not to do and figure out strategies to avoid following in its footsteps.
As though negative past experiences and a growing relationship with Wikia were not enough, Wikimedians have also become increasingly concerned at the emergence and growth of experimentation on the projects.
The proper role of experimentation is incredibly tricky to tease out. Some of the ethical questions are enhanced on Wikimedia projects because of the volunteer nature of most project participants and the complex relationship between the Foundation and the volunteer editing community.
The Foundation sees it as acceptable to experiment on users. In the Foundation's eyes, users are viewed and treated as customers, not colleagues. This is very dangerous and is a major contributing factor to the wariness (and weariness) with which Wikimedians view the Foundation. There is a cost to any of these experimental features on the editing community, and user experience is difficult to optimize under even the best circumstances. A keen understanding of user workflow is required to make non-disruptive, helpful changes. Many Foundation employees don't understand editor needs because they are not editors. In place of this understanding is the view, as expressed by one Foundation employee, that "we will allow ourselves to behave like elephants from time to time and we expect to be suffered."
Wikimedians are rightfully skeptical.
How do we move forward? The past and the present are interesting to focus on, but the future is of most concern.
The lines of communication between the editing community and the Foundation must be opened. It's not just about soliciting feedback; it's about engaging in useful conversation and adapting ideas accordingly.
With any big change, it helps to be up-front and to give a lot of warning about upcoming changes. People, particularly volunteers, do not like unexpected changes. The Vector roll-out was a slow process and that slow speed helped a lot. Posting mock-ups and design documents on MediaWiki.org (as all engineering projects are now expected to do and are actually doing) is a great step forward. Adding notes to the top of the page that make it seem like outside contribution is unwelcome is a small step backward. The Foundation should not be posting op-eds in which it lays out "changes you should expect to see". Rather, it should post design documents and other pages on mediawiki.org and in other public places that convey a different message: "These are our current thoughts; how can we make this better? What problems do you anticipate with these ideas? Can you suggest any alternatives?". This attitude of publishing edicts on design or features engenders yet more hostility and distrust of the Foundation.
Take a deep breath
The good news is that, despite the somewhat bleak picture painted in this piece, the Foundation does finally seem to recognize some of the big, scary, and difficult problems editors are facing. These problems are now receiving attention and resources. But there's the question of follow-through: Will the Foundation continue to abandon software behemoths? Will VisualEditor be the next LiquidThreads, and Wikidata the next FlaggedRevs?
To its credit, the Foundation has been snapping up every available Wikimedian with an interest in this area of work. A number of trusted and respected Wikimedians now work for the Foundation, easing concerns that it's out of touch with the editing community. Even old hands such as James Forrester and Brion Vibber have now joined or rejoined the Foundation, signaling good forces at play.
There are a lot of smart and dedicated individuals both in the Wikimedia editing community and working for the Foundation who want to see good changes happen. MediaWiki is a classic jack of all trades, serving no project well, a few projects passably, and most projects poorly. But despite ill-fitting and antiquated software, Wikimedians have created amazing content. With better tools (such as a fully functional visual editor and a sane communications infrastructure), there will be even better content. The Foundation understands this; the question is whether we'll see the fruits of its labors. Wikimedians need to remain vigilant about how resources are used, and they need to question the Foundation's output. There needs to be more dialogue and engagement between the community and the Foundation.