
Why designing for open source can be difficult - gilli
https://gilli.is/journal/why-designing-for-open-source-can-be-so-difficult
======
jbk
Oh boy, we're redesigning VLC interface those days, and does this article is
spot on on numerous part we've seen.

0\. A lot of things are not-intuitive, and we've had to do basic UX and
looking at our users to understand what the needs where (we don't use
telemetry/spying). And it took a lot of time...

1\. And yes, this requires to rethink some of the basics stuff for VLC usage.

2\. And the nerd-porn part is very true: we solved it with 3 layers of access.
Simple usage should be direct, Advanced usage for normal users should be
within 2 clicks, and Geek/Pro options can be further away.

And we will have options for different usage of VLC that will impact a bit the
UI (but we're making that as simple as possible, to not make the codebase too
complex -> more time)

3\. Finally, a lot of things had to be decided without consensus, and that
requires leadership that is not the usual way we work.

I can share some of the work, if some people care...

~~~
jackewiehose
> we're redesigning VLC interface those days

why?

~~~
jbk
> why?

Because this is the now main complaint we receive and because the usages are
changing.

But we will do our best so that the people who just use the basic player don’t
have much changes for them.

~~~
jackewiehose
> But we will do our best so that the people who just use the basic player
> don’t have much changes for them.

Ok, thanks, I hope so ;-) I was asking because for me the UI is fine and
usually when software gets "redesigned" for no apparent reason it means
features get removed because "simplicity".

~~~
jbk
> I was asking because for me the UI is fine and usually when software gets
> "redesigned" for no apparent reason it means features get removed because
> "simplicity".

We are not removing features. If a feature is removed, it is a bug, and it
will be fixed.

Seriously.

~~~
justinclift
Hmmm, how about the problem bug you can't have "[" or "]" in the directory
name of media files?

eg: /home/user/stuff/foo [192kb]

Worked fine with VLC 2.x, but VLC 3.x won't find the files in the directory.

It was _really_ annoying having to go and manually rename lots of directories,
recreate .m3u files to match, etc. Wasted hours on it. :(

------
eitland
> 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.

Serving average users by providing sensible defaults is a good idea but why
does so many think that removing settings is a natural next step?

I've joked[0] about making a slide deck and start selling training to every
modern software company :

> _Have your cake and eat it too!_

> How to please all your customers at once - Combining sensible defaults with
> the forgotten art of making your software configurable.

[0]: [https://erik.itland.no/courses-id-like-to-
teach](https://erik.itland.no/courses-id-like-to-teach)

~~~
defrex
Multiple configurations are a maintenance burden. So, all else being equal,
it's better not to have them. That said, not all else is equal, and
configurability can indeed increase the user experience. But if your defaults
are so good that very few people take advantage of the settings, you're better
off dropping them.

~~~
bityard
At what point does user experience trump the ability to use the software at
all in the first place?

UX designers are often seduced by reductionism because it makes their lives
easier and combined with various hand-wavy aesthetical rationalizations,
proceed to ignore several immutable aspects of reality:

Developers of an open source project usually have little insight into how
their project is actually being used out in the real world. They only know
about their use cases and (if they're lucky) that of their co-maintainers and
bug reporters.

If at some point in time, an option was added to make some piece of the
project do "x" instead of "y", it is overwhelmingly likely that the option
_was put there for a very good reason_. Just because you don't know the reason
doesn't mean one doesn't exist.

If the project has more than a few dozen users worldwide, then it is extremely
likely that for every UI widget, command-line option, or configuration
setting, there is a non-trivial subset of users who rely on that thing being
there for their workflow. Remove it, and at best you lose those users. But
more often you make them angry as well.

When looking at others' code and designs, it is a very human trait to assume
that the person who created it didn't know what they were doing and that the
way _you_ would do it is better. I get this and I fall into this trap more
often than I would like to admit. _But it is almost always wrong_. We often
look at the code in a vacuum and don't see the context under which is was
written and why it is still there.

I've watched this happen time and time again with various open source
projects: Person (or team) creates a successful project, maintenance of the
project shifts to a new person or group who decide that the old project was
"unmaintainable" and decides to a ground-up rewrite into what they _think_ is
going to be a better version of the same thing. When in reality, all they have
done is written a new, far less useful version of a somewhat similar thing.

Citation: [https://www.joelonsoftware.com/2000/04/06/things-you-
should-...](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-
do-part-i/)

------
ekidd
> _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._

A few large open source projects have tried to improve usability by removing
features and options. Look at the history of Gnome 1 through 3. Professional
UI experts were paid to produce usability advice for Gnome[1], and the Gnome
developers responded with the wholesale removal of configuration options
across dozens of major programs[2].

Mostly I actually liked this, because I prefer clean programs that I don't
have to mess with. But a lot of other users were unhappy, because many desktop
Linux users prefer knobs. Which is fine!

But what about Windows users and open source applications? Here, success may
be more of a mixed blessing. I've heard several open source maintainers say
that their Windows users are more likely to get angry with volunteer
maintainers, and to display the sorts of behaviors mentioned in [3]. So
widespread popularity isn't always a goal. Sometimes people just want to make
a niche tool for other enthusiasts.

So it's worth asking whether any given project is seriously trying appeal to
"the average user who just wants to get things done." Some are, some aren't.

[1]
[https://people.gnome.org/~calum/usability/ut1_report/report_...](https://people.gnome.org/~calum/usability/ut1_report/report_main.html)
[2] [https://ometer.com/preferences.html](https://ometer.com/preferences.html)
[3] [https://medium.com/@fommil/the-open-source-entitlement-
compl...](https://medium.com/@fommil/the-open-source-entitlement-complex-
bcb718e2326d)

~~~
chrisseaton
> Sun GNOME Human Computer Interaction (HCI), Sun Microsystems, Inc

Do you know the story behind why Sun was doing this work? I had no idea they
were involved in this major culture shift in Gnome. I thought they were more
invested in CDE.

You can see their focus - business users, scientists, creatives - and how that
might have led to the current design philosophy of Gnome.

~~~
bkor
> Do you know the story behind why Sun was doing this work?

See e.g. [https://www.gnome.org/press/2000/08/sun-joins-gnome-
foundati...](https://www.gnome.org/press/2000/08/sun-joins-gnome-foundation/).
Quote:

> Sun Microsystems, Inc. announced it is joining the GNOME Foundation [..] Sun
> also announced it will adopt GNOME 2.0 as the future desktop for its
> Solaris[tm] Operating Environment.

Be warned, above announcement is from August 2000.

~~~
Carpetsmoker
OpenSolaris used Gnome2 by default until Oracle killed it.

~~~
yjftsjthsd-h
And I believe OpenIndiana is still using MATE as their default DE, which is...
sorta funny actually; the fork/continuation of OpenSolaris running the
fork/continuation of GNOME 2.

------
laurent123456
> 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

I think that's the key. Unlike software development, where you can improve
things here and there incrementally, with design you need to have an overall
view of what you want to do, where you want to get, how the final product
should look. You can't tweak a margin here, add a border there over time, it
doesn't work.

And indeed, I suspect that's also why there are so few designers contributing
to open source. Anything of value they might suggest often means a big
redesign of the app, which nobody will be willing to do. It's a tricky issue,
to which there's no easy solution other than spending a lot of time and/or
money, both of which are often lacking in open source projects.

~~~
umvi
> Unlike software development, where you can improve things here and there
> incrementally, with design you need to have an overall view of what you want
> to do, where you want to get, how the final product should look.

There's a downside to this too though. Take swagger-ui[1] for example. A few
years ago I installed it at my company. It was great. Then managers wanted
more features, so I peaked into the source and found it wasn't too hard to
augment the HTML/JS. I added a search bar to filter HTTP APIs by dynamically
altering the JSON document. I added a button to generate a PDF. I added a drop
down to select release version from a database. It was quick and easy and
hackable.

Then they got sponsored and redesigned it from the ground up "professionally"
using React. I recently tried to upgrade to the latest version and... the
level of complexity has gone up several orders of magnitude. Whereas before I
just opened index.html and started hacking, now there _isn 't_ an index.html
at all. It's all a labyrinthine nest of components and configuration files
that somehow get magically compiled and bundled with some build process and I
have no idea how to even start porting my features over.

I suppose it all makes sense to full-time React developers, but seeing as I
mainly work in embedded Linux drivers, I don't really have a desire to learn
React since I was previously coerced into learning AngularJS which I now
regret.

So I guess my point is: if you pull in professional designers to design your
FOSS, it may become less accessible and hackable for non-designers like me.

[1] [https://github.com/swagger-api/swagger-ui](https://github.com/swagger-
api/swagger-ui)

~~~
iudqnolq
I don't understand how professional designers lead to React. It sounds like
funding let to more complex design and more complex development, but those two
don't lead to each other. I highly doubt many professional designers will
insist that you have to implement their design with a specific library, much
less do so themselves.

~~~
umvi
Professionals are going to use the latest and greatest tools at their
disposal, aren't they? For web developers, that seems to be esoteric
frameworks (React, Vue, Svelte, Webpack, Babel, etc. etc. etc. whatever the
cool kids are using these days)

Compared to non-professionals who stick with tried-and-true glue (vanilla js,
html, php, python, etc.)

It would be like if Jenkins got a sponsorship, so they hire professionals who
rewrite the entire thing in Rust because it's the best suited for the job by
the professionals' reckoning. Never mind that barely anyone knows Rust
compared to Java.

~~~
catalogia
> _Professionals are going to use the latest and greatest tools at their
> disposal, aren 't they?_

Some might do that. Others might well tell you they have a professional
obligation to make sound engineering decisions rather than chasing trendy
ephemeral fashions.

------
bluetomcat
The FOSS development model is best suited for modular software where you have
a relatively stable core and dozens of independent plugins for different
purposes by different authors, all implementing a well-defined interface. Any
new contributor adds stuff in parallel, without being blocked.

Other kinds of software which are a particularly good fit are non-end-user-
facing middleware and libraries implementing a standard or a protocol. That
standard or protocol pretty much describes what the software must do, and FOSS
software often becomes the "reference implementation". Think of zlib, libpng,
ffmpeg.

For the regular monoliths you need a team that is much more well-knit and
communication and focus is key. Each unit of code has a lot of dependencies
and it can quickly get out of control without any "social" coordination.

~~~
umvi
> and dozens of independent plugins for different purposes by different
> authors, all implementing a well-defined interface. Any new contributor adds
> stuff in parallel, without being blocked.

This reminds me of Jenkins, which is the most nightmarish piece of software
I've ever worked with. The plugins are of such wildly varying quality that
it's hard to tell if something broke because of a plugin you just
upgraded/installed, because the VM Jenkins is on got upgraded etc. And it's
plugins all the way down. Plugins built on plugins. So if you try to file an
issue with one plugin, they'll often just point you one plugin down the stack.

You get what you pay for, I suppose, and obviously a lot of people like the
tool.

~~~
catalogia
Jenkins goes south because the people using the system aren't the people
configuring the system.

Consider instead a system like emacs, firefox, or mpv. Where the
plugins/extensions/scripts are selected and configured by the person who's
actually using them. Choosing what they want ignore what they don't, the
result is a system that's understood by the person who actually uses it.

------
eandre
I agree with the article and am facing the same challenges in my own startup:
how much, and what, to open source?

It's a platform that offers a simpler way of building serverless backends [1],
and so it's naturally targeting developers. As a developer myself I know how
much I appreciate things being open-source and free. At the same time it would
come with huge business model challenges in my case and kind of erode what my
product is all about (simplicity and having things taken care of for you).

While the article does not really offer any answers, I'm curious if anyone
else has any experience to offer in this regard?

[1] [https://encore.dev](https://encore.dev)

~~~
zomglings
I'm in a similar position as you. Our decision was to open source our
underlying framework but none of our infrastructure code:
[https://github.com/simiotics/shnorky](https://github.com/simiotics/shnorky)

Our customers pay us for peace of mind, which takes work (and automation)
beyond the core functionality of the open source product.

Happy to discuss further.

------
zakum1
I don’t think that the “nerd porn” is as negative as the writer believes. If
we compare FOSS to proprietary enterprise software we see how little regard
proprietary vendors often pay to what engineers need at the expense of adding
check-list features that attract “business” decision makers. The ability to
enhance, operate, monitor, test are so much stronger in FOSS products because
they are written for engineers by engineer. This can of course be taken too
far, but it is, IMO, a reason why FOSS can succeed in displacing proprietary
technology.

------
generationP
This minimalism fetish is grating. Guess what you need to "just wants to get
things done"? Features. If you're in luck, these are standard features, but if
not, they will be exotic features that would never be built under that "less
is more" philosophy. And it's misleading to think that by only implementing
the most popular core features, you'll make the most users happy. Projects
often _rely_ on those power users using their software, as these same power
users will then advertise it by visibly creating great stuff in it and
document it on sites like superuser.stackexchange. Not to mention that while
every single exotic feature may only get used by 1% of your userbase, chances
are most users will at some point need at least one such feature and would get
disappointed by its lack.

A lot of highly popular contemporary open-source tools are feature-rich.
Foobar, Winamp and VLC are all full of stuff you won't need (but what this
stuff is depends on you) and extendable. Notepad++ has perhaps the largest
number of menu items I've ever seen in a program. Not to mention browsers
(whose feature creep is legitimately dangerous, and yet necessary), classic
linux tools, office suites, IDEs, PDF editors... Even in the author's example
(a sync tool), I'm not sure I agree. Dropbox with its (relatively) minimalist
design was fun until at some point it broke for me (getting stuck in an
endless sync loop). With some debug info, I may have found the issue and
gotten it to work. The way it was, I just switched to Onedrive.

A more reasonable rule is probably "don't include features that could be split
off into a separate tool without loss of efficiency or functionality".

~~~
theandrewbailey
> A lot of highly popular contemporary open-source tools are feature-rich.
> Foobar, Winamp and VLC are all full of stuff you won't need (but what this
> stuff is depends on you) and extendable.

I'm not sure if you're implying that Foobar and Winamp are open source. They
aren't.

~~~
generationP
Oops, I should have said freeware. (Though I thought of foobar as being OS for
some reason -- probably from its aesthetic and design. Winamp, of course,
predates the big wave of OSS for Windows.)

------
jaredtn
I recently released an open-source framework for machine learning debugging.
Proper discipline can be the difference between wild success and a your
project slowly sinking, like a stone to the bottom of a river.

Why? Because a customer adopting your product is risky, dangerous, and
uncertain for them. They’re squeezed for time to learn your paradigm. They’re
staking their reputation on the line with a boss, coworkers, and company.

The great irony is, that by adding features to support one additional
customer, you harm the ten customers you already have. Ten happy customers
become eleven “okay” customers, then twenty unhappy ones. Make the interface
too complex? People will quit. Too many widgets, settings, and knobs will
torpedo a project in no time.

------
iwalton3
I personally prefer that applications have ideal defaults instead of removing
features. It should be easy to pick up an application and use it, but if you
want to change something, you should be able to. This can be by using the
settings dialog, or for particularly advanced features, by editing a config
file. Some users have needs that cannot be met by a bare-bones application,
and usually these users depend on Open Source applications that either
implement their needs or allow them to change it for their uses.

------
bawolff
Lots of this rings true, but i disagree about people only want to do the fun
things.

First of all often what one person considers boring another considers fun.
Optimization was used as an example, but often optimization can be really fun
(its like a puzzle). More generally, in my experience with an open source
project that has both volunteers but a majority of paid devs (MediaWiki),
often the volunteers are motivated by making it work well for their niche and
will take on really annoying projects important to their niche that have been
ignored by the paid devs as not being cost-effective or a priority for
whatever reason.

------
jancsika
> 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.

There's one case I've run into where themes are great. That is when one wants
to improve a craggy FLOSS interface. Invariably a craggle will ask for an
option to turn the ugliness back on and a non-default theme provides the
perfect place to do that.

------
cxr
Bibliographic info for that sweet engraving is here:

[https://www.oldbookillustrations.com/illustrations/corliss-s...](https://www.oldbookillustrations.com/illustrations/corliss-
steam-engine/)

[https://openlibrary.org/books/OL13511601M/Appletons'_cyclopa...](https://openlibrary.org/books/OL13511601M/Appletons'_cyclopaedia_of_applied_mechanics)

------
comis
In general I feel that developers are very poor clients. Designers are better
off finding freelance work or donating time to a non-profit they care about
imo.

