Why designing for open source can be so difficult

After being involved with design and open source projects for many years, I've noticed a few common reasons why designing for open source projects can be very difficult. Open source projects (especially FOSS) face a lot of issues that more conventional projects don't because they lack a clear business model, the structure, and the incentives that for-profit proprietary projects have.

Nerd porn

A lot of open source projects suffer from too much of what I like to call, nerd-porn. It involves displaying as much information about what is going on at any given time as possible, which nerds love. Don't get me wrong though, I'm a nerd, and I like nerds.

But the trouble is that most of that information is not that useful except maybe if you are a developer debugging the product. But, as if that isn't enough, nerd-porn lovers also want to be able to tweak everything to fit their taste perfectly.

Adding features and settings is fun and often done without much second thought. In the end, it results in a bloated beast that causes a lot of confusion and frustration, especially among the type of users most open-source projects are missing, the average user who just wants to get things done.

All this clutter is followed by adding optional themes as a solution to the complaints people have about the user experience, which, in my opinion, can never fix the problems because they go much deeper than the superficial surface, and that is all that a theme can fix. But it can require a lot of refactoring and changes to fix the user experience.

I prefer serving the average user who doesn't have time to dive into the settings and tweak everything before he is finally able to use the product. Striving for ease of use removes the need for most settings. If you're interested in reading a case study where I redesigned an open source that had these issues, check this case study out.

Decision making

Many projects don't really have any real leadership which can lead them to end up being a bit aimless and unable to focus on what is essential for its success.

Getting people to focus on a clear goal is easy when money is involved. There is a big incentive to build for your user because he is the reason you are able to buy bread for your family.

But open source projects often don't have that incentive. They are worked on by volunteers who give away their free time and get very little in return.

As a result, contributors often only want to work on the fun stuff, like adding new features. But nobody wants to work on the boring, but arguably more important, things like optimisation or modifying complicated code to improve the user experience. Because after all they are doing this in their free time and most likely spent their day dealing with boring stuff at work.

In addition to all this, there is often a lack of a clear decision-making process. Nobody wants to be a dictator and, if there is no clear process in place, all the discussion leads to bike shedding.

Designers and developers

I think a part of the reason why more designers don't contribute to open source is that often it requires you to rethink the entire product from the ground up and make changes that require someone else to do a lot of work. And maybe even remove features that blocking a good experience. That's actually how I start every project I work on, I dig in and question everything and make sure to strip it down to its bare bones and build it back up with a clear focus.

I think removing features is possibly one of the hardest things to do for an open source project because there will always be that one guy who really, really, really wants that feature and will be very vocal about it. For a project with a financial incentive, this is an easy decision to make. But for an open source project, this can lead to an endless discussion spanning many months. On top of that, someone may have put a lot of work into building that feature and might feel insulted if it is deleted. All this can lead to a lot of resentment and drain the energy out of the project.

Conclusion

I think the best way to solve these issues is to make the projects goals clear right from the start, who is it for? Is it for specialists or average joe? Who gets the final say? Who is in charge of making sure the discussion doesn't go on and on forever while making no progress? And how will you handle significant changes that are holding the project back?

Finally, I want to give a shoutout to Open Source Design, which I've been a member of for a long time, and whose goals are to improve open source design.