What’s a User?
This is the second part of a larger series on software design, user experience, FOSS, and more. While reading the first part is not required, if you’re interested, click here.
Content warning: this post features light analogies toward abusive parenting, and mentions of totalitarian regimes.
Most developers, particularly those in FOSS, treat the software they make like a child of their own. In general, people tend to refer to projects with some kind of sentimental value as their “babies,” and honestly, I’m going to be using this analogy a lot. It just really fits, because depending on who the developer is, they either want to help their child grow and prosper and change the world, or they want to control every aspect of their child’s existence and make sure the child grows up in exactly the way they think their child should.
And sure, that’s an extremely charged way of putting it, and it makes every developer who’s got a vision for their project seem like an abusive parent who wants to control every aspect of their actual, human child’s life. That’s a huge difference, and I don’t want to make light of that. However, the decisions that developers make have on their software projects can have a huge impact on people’s lives, and I don’t want to make light of that either.
Ultimately, having a healthy relationship between developers, projects, and their users is beneficial in almost every case, and if you’re going to call a project a baby, you should try to be a good parent.
My software baby
Most software projects in the FOSS community are run by a single person, who takes the role of both lead developer and project manager. Why this happens isn’t much of a surprise: a lot of developers set out to solve a particular problem that they themself had, and making the software open-source simply lets other people who had the same problem use that developer’s solution. While it may seem that developers are being hostile by not adapting to other people’s needs, really, that wasn’t ever part of the plan in the first place.
While a lot of these projects do accept outside bug reports, feature requests, and contributions, it’s entirely at the discretion of this single person whether reported bugs are worth fixing, requested features are worth implementing, or contributions are worth including and maintaining. And that last part, maintenance, is a hugely cited reason to reject everything that shows up at a developer’s metaphorical doorstep. Any new feature that’s added to a project often has an associated cost in the form of new bugs to fix, or extra work required to avoid breaking that code when doing other work.
And again, a lot of developers see things this way because they see their project like their own, literal child. They’ve got to be the one to watch the child grow, and they’ve got to be the one to change their child’s diapers when things get smelly. This isn’t necessarily because no one else is around to do this, but because the head developer has taken these responsibilities onto themself and themself alone. And sometimes, this one developer actually is the person for the job, a true BDFL, but not always. Usually, the “benevolent” part of BDFL is just a not-so-funny joke.
And you see, there are a lot of genuinely good reasons for all of these decisions, and maybe the true benevolence is just the fact that these people offered their code up in the first place. It’s easy to point fingers and call someone a bad parent when they’re really not at fault. And it’s very important to go through these reasons so we can actually have a better understanding of when and why a BDFL is at fault, and why having a BDFL is a bad idea in the first place.
Giving birth to a law-abiding citizen
In FOSS, unlike other types of software, you can fork a project to continue its development separately from its original developer or development team. As long as you follow the restrictions of the software’s license, like giving credit to the original author or ensuring that the software remains open-source down the line, you can “branch off” of the original project and create a copy which eventually goes down a different path than the original.
A lot of developers use the option of “forking off” as a reason to not accept contributions from people which otherwise clash with their ideology or the project’s development plan. In other words, if you don’t like how I’m doing things, fork off. And a lot of the time, a fork really isn’t viable, and “fork off” is really the “fuck off” the developer intended. That said, it’s worth mentioning that a lot of very successful software projects started out as forks.
For example, around ten years ago, OpenOffice.org was the most popular open-source replacement for Microsoft Office. At the time, development was managed by Sun Microsystems, who wasn’t super great at getting features out quickly, but wasn’t super bad at it either. Once Sun was bought out by Oracle in 2010, a large portion of the development team were incredibly worried about Oracle either abandoning the project or continuing to develop the software as a paid, closed-source version, and forked the project into the now-successful LibreOffice. And, because the development of LibreOffice is bound to a community, rather than a company, feature development has been a lot faster and better.
OpenOffice, by the way, still exists as a project managed by the Apache foundation. In the FOSS world, mostly because of this very example, giving a project to Apache is generally a euphemism for killing a project.
Another example of a successful fork is Gitea, an open-source replacement for the website GitHub which was originally forked from Gogs. You see, Gogs was (and still is) developed by the Chinese developer @Unknwon, who acts as the lead developer and project manager for Gogs. Because a lot of users and contributors to the project were frustrated with the pace of the project, as everything had to be approved by @Unknwon himself, they forked the project and have since managed to implement a lot of features that wouldn’t be possible in Gogs by itself.
Honestly, when I started writing this post, I thought of Gogs exactly like OpenOffice in the sense that both had one problem that needed to be overcome: the entity (person or company) in charge. In fact, Gitea is the reason why I adopted the parent-child analogy in the first place, as shown in their original post about forking from Gogs:
@Unknwon rightly considered Gogs his own creature and didn’t want to let it grow outside of him, thus a fork was necessary in order to set that code effectively free.
As Kahlil Gibran wrote about children:
Your children are not your children. They are the [children] of Life’s longing for itself. They come through you but not from you, and though they are with you yet they belong not to you.
And this all feeds back to what I said at the beginning of this post. While some developers genuinely are an abusive parent who needs to let their child flourish without them, there are often other reasons beneath the surface. And I didn’t realise how aptly this fit Gogs’ case until I read @Unknwon’s bio on GitHub:
To be a rich man who has contributions to the country and the society. Obey to the laws and regulations that applies.
Right. I knew that @Unknwon was Chinese, and I knew that China was a totalitarian regime that uses extremely scary tactics to control its population, but I guess that I never really connected those two dots until just now. To him, creating Gogs is just part of being a good citizen. It doesn’t make sense for him to relinquish control of the project to anyone else, unless other people being added onto the project have the same love and support of the Chinese government he does. Even though most of the users of Gogs aren’t Chinese, and @Unknwon wants to make the project popular across the world, he doesn’t actually want these people in control of the project, for good reason.
And honestly, this case is more in support of my original points. While it makes absolute sense for the developer of Gogs to not allow anyone else on board, for pretty much everyone besides him, it ends up hurting the project. And while @Unknwon actually has good reasons for doing what he’s doing, most projects don’t have to satisfy the concerns of Big Brother, and letting more people change their baby’s diapers might ultimately be for the better good of everyone, the original developer included.
Free as in free to give you the middle finger
Ultimately, the word needs free and open-source software. And here, the “free” part often means both free of charge and free of restrictions, to ensure that everyone has access to the software and can reap its benefits, which are usually in the form of making something easier to do. Being open-source allows anyone to suggest and make changes to the software itself, and it allows people to audit the software to make sure they know what it’s doing.
Software which isn’t free and/or isn’t open source simply can’t accomplish these goals. And as you might have noticed, “freedom” and “openness” aren’t really a yes-or-no thing; something can be partially free or partially open, and whether we truly call these projects FOSS can be open to debate. For example, the Free Software Foundation, who advocates very strongly for FOSS, argues that selling FOSS is okay, as the real “freedom” is being able to use the software how you want and access its source code. To the FSF, “free as in freedom” only applies to users of software, and if you don’t have the cash, you can’t use it.
One of the most commonly ignored aspects of software freedom is the freedom to openly contribute to a project. As we mentioned earlier, the BDFL model is entirely against the spirit of this; if you and the BDFL clash in views, then you can’t make the changes you want or need. Companies can also act as BDFLs, and in many ways they’re far worse than individuals.
While being open source is supposed to improve the ability to contribute to the project, sometimes, it really doesn’t. For example, Vala, the programming language developed by the GNOME project, is open source. However, the source code is incredibly hard to read despite being formatted, and it looks like it was intentionally obfuscated for one reason or another. A lot of projects, despite not being intentionally obfuscated, have very little documentation and aren’t really designed to be looked at by other people. In these cases, does being open source really contribute to the freedom of the software?
And again, all of this brings us back to the discussion of “freedom,” and why people really make FOSS in the first place. Before, we mentioned that most FOSS comes out of a problem a developer set out to solve, for themself, but that’s not entirely the full story. Many FOSS developers believe in the idea of software freedom, and specifically create software because they want users to be able to use free alternatives to existing tools. If that’s the case, why are they so abrasive? Why are developers so unwilling to work with others when their visions clash? If the point was the freedom of the user, then why doesn’t the user have any say?
Marketing your new, innovative product
One of the biggest problems with designing anything, software only being a small example, is figuring out who your users are. In order to truly know how people are going to use a piece of software, you need to actually know what you’re building. But, to know what you’re actually going to build, you need to know how people will use it. This brings us back to the reason why BDFLs exist: most developers design things for themselves, and all other users are a bonus. If you’re the sole designer, developer, and user, you can adapt what you build to fit your needs.
Honestly? No one has any idea how a piece of software will be used beyond the vague notion of “I think people will want this,” and in FOSS specifically, it rarely extends beyond “I want this, therefore other people will want this.” And we can extend this to companies too— most companies start with a product idea, and even if there’s research involved, it ultimately boils down to a slightly educated guess at “I think people will want this.” You can ask people if they want it, and they might say yes. But until a user actually has a piece of software in their hands and knows what they want to do with it, it’s just a guess.
This is why we see so many half-arsed ideas come out of startups that seem obviously bad on the surface, to the point where we wonder why they even thought the idea was good in the first place. Juicero is a good example; at first, it seemed that having a machine that can make you fresh-squeezed juice in the mornings would be a great new product. During the actual execution of this idea, they ended up making a 400$ machine that squeezed bags of fruit about as good as you could do by hand. Did they know that their plan of making a fresh-juice-squeezing-machine would end up this way? Honestly, I doubt that was the intent from the start; they could have genuinely thought that such a machine was possible to build in a way that wasn’t as easy as squeezing by hand. It just wasn’t.
You could argue that this is a just technical problem, but it really is a user problem. The kinds of users who want this kind of easy, fresh-squeezed juice really don’t care about the end result; they care that it “feels” like fresh, squeezed juice. And if they can just squeeze the juice out of these pre-processed bags, all of that magic gets lost. The kinds of people who would buy Juicero really have the money to spend on a worthless 400$ machine, but they won’t spend that money if the experience isn’t there. And despite the amounts of research they did or didn’t do to figure out who their users were, ultimately, it was just a guess, and their guess was wrong.
And obviously, a lot of companies aren’t okay with the fact that they have to guess. And this is where marketing comes in— if you can convince people that they have a use for your product, whether they actually need it or not, you’ll have more users than just those who actually have a use for it. And note that this is different from advertising, where you’re just making people aware of your product. Marketing is all about convincing people to use your product.
And of course, both of these form a spectrum, rather than two discrete ideas. As part of marketing, you have to tell people what your product is and what it does before you can start convincing them to use it. Similarly, as part of advertising, explaining why someone might want to use your product is just part of telling them what it is. Rather than describing something as “advertising” or “marketing,” it’s more accurate to say where something lies between the two.
And while the two end up doing about the same thing, their motives are totally different. If your primary goal is advertising, then you care most about spreading information, and it’s in your best interest to make sure that things are represented as truthfully as possible. In marketing, however, your only goal is to convince people to use your product; truth is optional. More succinctly, advertising cares about quality, and marketing cares about quantity.
Free as in free him
If we’re going to figure out what we’re building, we need to know how people will use it. In order to know that, we need people. So, we’ll market the idea to them and see how they think, right?
Right. Marketing is fundamentally about changing people’s perceptions in favour of your product. How many times have you shown a friend something you’ve made or done and had them say “looks great”? If you set something up in a way that people have to like it, lest they feel bad, unintentionally or not, you’re not actually getting useful feedback. A lot of people look at the numbers, the raw quantity of users obtained, and use this to judge whether they’re doing a good job. And this makes it so easy to mess up.
Again, back to the baby analogy: parents want their kids to be successful. If you throw your kid a big birthday party and invite all the cool kids, then you can show just how great your kid is. You love my baby, right? Right?
Many FOSS developers rely on the idea of “software freedom” to market their creations. And honestly, being free is something you should genuinely celebrate— as long as your software is actually free. And honestly, we can replace “free” here with just about any term and it’d still apply.
Software is entirely about its users. If you don’t know who your users are, you know nothing about what your software is. For example, on Linux-based systems, there are multiple choices for desktop environments, i.e. the software that manages where all the windows go, what the menus do, and basically how you navigate the most basic aspects of your average PC.
What’s the difference between GNOME, KDE, Xfce, and Pantheon? Who uses them? Why do they use them? If someone comes to me and asks me which they should use, which questions do I ask? If someone goes and “installs Linux,” what do I do? It’s really easy to get stuck into explaining “what” your software is and thinking you’re done, but this information often doesn’t really help at all.
Facebook is a social media website. Twitter is a microblogging platform. Medium is a blogging platform. Or is it a macroblogging platform? What’s a blog, again? Can I blog on Facebook too? Is Tumblr really a blogging platform at all? Ask your friends what social media they use and why; you'll get a load of different answers. And this isn't because we've failed to find the right word, or because your friends are ignorant or incompetent— it's literally what's supposed to happen.
If your goals are to genuinely make a good piece of software and nothing else, then you should talk to users and understand what goals they have in mind. Finding users should be done exclusively through advertising, and not marketing. And rather than prioritising a lofty vision of what you want, think about what your users want.
It's time to let your baby go.