This month a Recurser I know, Pepijn de Vos, observed a concentration of high-quality open source software in the developer tools category, to the exclusion of other categories. With a few exceptions.

I understood where he's coming from, though my assessment differs. I started reflecting on those exceptions. Do they "prove the rule" in the colloquial sense that "every rule has exceptions," or do they "prove the rule" in the older sense, in that they give us an opportunity to test the rule? A few years ago I learned about this technique called "appreciative inquiry" which says: look at the unusual examples of things that are working well, and try to figure out how they've gotten where they are, so we can try to replicate it. So I think it's worth thinking a bit more about those exceptional FLOSS projects that aren't developer tools and that are pretty high-quality, in user experience design and robust functionality. And it's worth discussing problems and approaches in product management and user experience design in open source, and pointing to people already working on it.

FLOSS with good design and robust functionality: My list would include Firefox, Chromium, NetHack, Android, Audacity, Inkscape, VLC, the Archive Of Our Own, Written? Kitten!, Signal, Zulip, Thunderbird, and many of the built-in applications on the Linux desktop. I don't have much experience with Blender or Krita, but I believe they belong here too. (Another category worth thinking about: FLOSS software that has no commercial competitor, or whose commercial competitors are much worse, because for-profit companies would be far warier of liability or other legal issues surrounding the project. Examples: youtube-dl, Firefox Send, VLC again, and probably some security/privacy stuff I don't know much about.)

And as I start thinking about what helped these projects get where they are, I reach for the archetypes at play. I'll ask James and Karl to check my homework, but as I understand it:

Mass Market: NetHack, VLC, Firefox, Audacity, Inkscape, Thunderbird, youtube-dl
Controlled Ecosystem: Zulip, Archive Of Our Own
Business-to-business open source: Android, Chromium
Rocket Ship To Mars: Signal
Bathwater? Wide Open? Trusted Vendor? not sure: Written? Kitten!

The only "Wide Open" example that easily comes to mind for me is robotfindskitten, a game which -- like Written? Kitten! -- does one reasonably simple thing and does it well. Leonard reflected on reasons for its success at Roguelike Celebration 2017 (video). But I'd be open to correction, especially by people who are familiar with NetHack, VLC, Audacity, Inkscape, or youtube-dl development processes.

Design: Part of de Vos's point is about cost and quality in general. But I believe part of what he's getting at is design. Which FLOSS outside of developer tooling has good design?

In my own history as an open source contributor and leader, I've worked some on developer tools like PyPI and a linter for OpenNews, but quite a lot more on tools for other audiences, like MediaWiki, HTTPS Everywhere, Mailman, Zulip, bits of GNOME, AltLaw, and the WisCon app. The first open source project I ever contributed to, twelve years ago, was Miro, a video player and podcatcher. And these projects had all sorts of governance/funding structures: completely volunteer-run with and without any formal home, nonprofit with and without grants, academic, for-profit within consultancies and product companies.

So I know some of the dynamics that affect user experience in FLOSS for general audiences (often negatively), and discussed some of them in my code4lib keynote "User Experience is a Social Justice Issue" a few years ago. I'm certainly not alone; Simply Secure, Open Source Design, Cris Beasley, The Land, Clar, and Risker are just a few of the thinkers and practitioners who have shared useful thoughts on these problems.

In 2014, I wrote a few things about this issue, mostly in public, like the code4lib keynote and this April Fool's joke:

It turns out you can go into your init.cfg file and change the usability flag from 0 to 1, and that improves user experience tremendously. I wonder why distributions ship it turned off by default?

Wikimedia and pushback: But I also wrote a private email that year that I'll reproduce below. I wrote it about design change friction in Wikimedia communities, so it shorthands some references to, for instance, a proposed opt-in Wikimedia feature to help users hide some controversial images. But I hope it still provides some use even if you don't know that history.

I wanted to quickly summarize some thoughts and expand on the conversation you and I had several days ago, on reasons Wikimedia community members have a tough time with even opt-in or opt-out design changes like the image filter or VisualEditor or Media Viewer.

• ideology of a free market of ideas -- the cure for bad speech is more speech, if you can't take the heat then you should not be here, aversion to American prudishness etc., etc. (more relevant for image filter)
  • relatedly "if you can't deal with the way things are then you are too stupid to be here" (more applicable to design simplifications like Media Viewer and VisualEditor)

• people are bad at seeing that the situation that has incrementally changed around them is now a bad one (frog in pot of boiling water); see checkbox proliferation and baroque wikitext/template metastasis

• most non-designers are bad at design thinking (at assessing a design, imagining it as a changeable prototype, thinking beyond their initial personal and aesthetic reaction, sussing out workflows and needs and assessing whether a proposed design would suit them, thinking from other people's points of view, thinking from the POV of a newcomer, etc.)
  • relatedly, we do not share a design vocabulary of concepts, nor principles that we aim to uphold or judge our work against (in contrast see our vocabulary of concepts and principles for Wikipedia content, e.g. NPOV, deletionism/inclusionism)
    • so people can only speak from their own personal aesthetics and initial reactions, which are often negative because in general people are averse to surprise novelty in environments they consider home, and the discourse can't rise beyond "I don't like it, therefore it sucks"

• past history of difficult conversations, sometimes badly managed (e.g. image filter) and too-early rollout of buggy feature as a default (e.g. VisualEditor), causes once-burned-twice-shy wariness about new WMF features
  • Wikimedians' core ethos: "It's a wiki" (if you see a problem, e.g. an error in a Wikipedia article, try to fix it); everyone is responsible for maintaining and improving the project, preventing harm
    • ergo people who feel responsible for the quality of the project are like William F. Buckley's "National Review" in terms of their conservatism, standing athwart history yelling "stop"

I haven't answered some questions: what are the common patterns in our success stories (governance, funding, community size, maintainership history, etc.)? How do we address or prevent problems like the ones I mentioned seeing within Wikimedia? But it's great to see progress on those questions from organizations like Wikimedia and Simply Secure and Open Tech Strategies (disclosure: I often do work with the latter), and I do see hope for plausible ways forward.