Including design and UX in a true community project is a challenging matter of balance because of the motivational model behind open source projects.

 

According to The Cathedral and the Bazaar, the key motivation for participants in open source projects is “scratching their own itch.” One consequence of this is co-ordination of contributions to support user-centric design is inherently an optional extra in a true open source project with multiple independent participants. We all wish there was a way to get genuine user experience quality as a key dynamic of open source projects. But there are two big reasons that is challenging.

First, individual users truly don’t know what all users want.

• To be clear, I am not repeating the trope that “users don’t know what they want”.
• Each user knows what they want, and those with the personality profile that allows them to express their desires articulately in public can often make a compelling case for their own needs.
• But an overall evaluation of “what users want” is perilously difficult to establish, even for corporations which can eliminate large numbers of voices with the requirement that payment must be made to have a qualifying opinion. Corporations employ Product Managers who use market research and personal experience to guide development. It’s a well understood job, but even with skilled product managers a proprietary project can miss the mind of the market.
• User voting is not the answer, as anyone who has seen it in action in Bugzilla can testify. I’m not convinced that user-funded bounties help identify broad user needs either, although they offer a useful avenue for funding some open source.
• All the same it is very common indeed, especially in end-user software, for users to show up demanding a feature be implemented or changed. I have often seen community members struggle to remain courteous to rude, entitled freeloaders demanding things they want from people they have never met and have no intention of thanking, let alone paying.
• Instead, users need skilled advocates speaking on their behalf, prioritizing features based on utility, demand and practicality and working with developers to advance the user experience offered by the software.
• They need to do so from a base of merit-earned status and not appointment.
• What I crave for open source software is thus a user experience centric approach, not a user-centric approach, and they are dramatically different.
• But that requires the appointment of a skilled user advocate, not the ad-hoc voices of millions of individuals or a self-selecting subset with type A personalities.

 

Second, developers in open source free software projects don’t take orders.

• That’s just a consequence of the model. An open source project arises where the intrinsic interests of many people overlap. The overlap does not make their intrinsic interests merge; it simply creates an area of their respective lives where they collaborate with others, or use the work of others with whom they have no other relationship.
• The lack of any other relationship is what makes software freedom so important. By guaranteeing that every individual can use, improve and share the software without reference to any other person or entity, we ensure each person is free to meet their own needs without interference.
• The corollary of that freedom is a lack of authority relationship. Two users who use the software in different ways are unable to force each other to change they way they use the software; if they want interoperable behavior they need to negotiate it. Two developers who earn their living from the software in different ways are unable to force each other to implement a feature that serves their needs. Instead they must implement the code they need and negotiate its inclusion with others. Finally a user wanting a feature implemented cannot demand a developer implement it. They might make it appeal to a developer, perhaps by paying them outside the scope of the project. But there is no basis for an authority relationship.
• This places the UX expert in an invidious position. A UX outlook is inherently the synthesis of user experiences, so represents no individual in its entirety. UX also involves directing others in how to shape their code, in an environment where power relationships are expressly excluded.
• Further, in a collaborative project, every participant pays their own way (rather than looking to the project for pay) and meets their own needs (rather than directing or paying the project to do so).
• A UX expert and/or “product manager” is also very unlikely to have an external motivation for their involvement. As a consequence, it’s quite unlikely that one of the collaborators coming to the project will be a UX practitioner and if they are, their external motivation for doing so will probably be a concern for the project.

 

That’s not to say projects are ignoring UX. Two examples:

1. Mozilla spends a significant sum on UX and has been able to elevate respect for UX so that it is a developer priority (although of course Mozilla is special).
2. TDF have recently decided to spend donated funds to retain a UX expert to support the LibreOffice developers (who are already supported by a good design team) and are in the process of exploring how best to help him interact with the developers, who are not under the majority control of any entity.

 

Self-reliance arising from motivations and rewards external to the project is a fundamental part of the open source model. While some are frustrated that the developers get to call all the shots, to challenge their power over the future of the project is to Quixotically confront a natural force that arises from inherent self-reliance and is doomed to frustration. Trying to shame developers into accepting your authority has a poor track record of success.

So if you would like to switch to a user-centric approach for open source development, you will need to answer the two questions that arise from the analysis above:

1. Which users will be at the centre, how do they get there, why are they the ones who should be there and who is representing them?
2. What will motivate the people who actually make stuff – developers, designers, documenters – to do the things they ask for.

 

We need to explore ways to build motivations for UX practitioners to join collaborative communities and mechanisms for their contributions to not violate the natural dynamics arising from the absence of authority relationships. Mozilla has one approach, and TDF another. Maybe others have approaches they can share and from which we can all learn? Let us know below.

---

This article was originally published in Meshed Insights, and was made possible by Patreon patrons.

Image credit:
“userCentric.jpg,” ©Open Source Initiative, 2017, Creative Commons’ Attribution 2.0 Generic (CC BY 2.0), is a derivative (scaled and cropped) of “Computer Expert“, ©Karen Baijens, 2015, via Flickr, and used with permission under Creative Commons’ Attribution 2.0 Generic (CC BY 2.0).