Why designing for open source can be difficult

Oh boy, we&#x27;re redesigning VLC interface those days, and does this article is spot on on numerous part we&#x27;ve seen.<p>0. A lot of things are not-intuitive, and we&#x27;ve had to do basic UX and looking at our users to understand what the needs where (we don&#x27;t use telemetry&#x2F;spying). And it took a lot of time...<p>1. And yes, this requires to rethink some of the basics stuff for VLC usage.<p>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&#x2F;Pro options can be further away.<p>And we will have options for different usage of VLC that will impact a bit the UI (but we&#x27;re making that as simple as possible, to not make the codebase too complex -&gt; more time)<p>3. Finally, a lot of things had to be decided without consensus, and that requires leadership that is not the usual way we work.<p>I can share some of the work, if some people care...

&gt; I prefer serving the average user who doesn&#x27;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.<p>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?<p>I&#x27;ve joked[0] about making a slide deck and start selling training to every modern software company :<p>&gt; <i>Have your cake and eat it too!</i><p>&gt; How to please all your customers at once - Combining sensible defaults with the forgotten art of making your software configurable.<p>[0]: <a href="https:&#x2F;&#x2F;erik.itland.no&#x2F;courses-id-like-to-teach" rel="nofollow">https:&#x2F;&#x2F;erik.itland.no&#x2F;courses-id-like-to-teach</a>

&gt; <i>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.</i><p>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].<p>Mostly I actually liked this, because I prefer clean programs that I don&#x27;t have to mess with. But a lot of other users were unhappy, because many desktop Linux users prefer knobs. Which is fine!<p>But what about Windows users and open source applications? Here, success may be more of a mixed blessing. I&#x27;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&#x27;t always a goal. Sometimes people just want to make a niche tool for other enthusiasts.<p>So it&#x27;s worth asking whether any given project is seriously trying appeal to &quot;the average user who just wants to get things done.&quot; Some are, some aren&#x27;t.<p>[1] <a href="https:&#x2F;&#x2F;people.gnome.org&#x2F;~calum&#x2F;usability&#x2F;ut1_report&#x2F;report_main.html" rel="nofollow">https:&#x2F;&#x2F;people.gnome.org&#x2F;~calum&#x2F;usability&#x2F;ut1_report&#x2F;report_...</a> [2] <a href="https:&#x2F;&#x2F;ometer.com&#x2F;preferences.html" rel="nofollow">https:&#x2F;&#x2F;ometer.com&#x2F;preferences.html</a> [3] <a href="https:&#x2F;&#x2F;medium.com&#x2F;@fommil&#x2F;the-open-source-entitlement-complex-bcb718e2326d" rel="nofollow">https:&#x2F;&#x2F;medium.com&#x2F;@fommil&#x2F;the-open-source-entitlement-compl...</a>

&gt; part of the reason why more designers don&#x27;t contribute to open source is that often it requires you to rethink the entire product from the ground up<p>I think that&#x27;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&#x27;t tweak a margin here, add a border there over time, it doesn&#x27;t work.<p>And indeed, I suspect that&#x27;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&#x27;s a tricky issue, to which there&#x27;s no easy solution other than spending a lot of time and&#x2F;or money, both of which are often lacking in open source projects.

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.<p>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 &quot;reference implementation&quot;. Think of zlib, libpng, ffmpeg.<p>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 &quot;social&quot; coordination.

I agree with the article and am facing the same challenges in my own startup: how much, and what, to open source?<p>It&#x27;s a platform that offers a simpler way of building serverless backends [1], and so it&#x27;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).<p>While the article does not really offer any answers, I&#x27;m curious if anyone else has any experience to offer in this regard?<p>[1] <a href="https:&#x2F;&#x2F;encore.dev" rel="nofollow">https:&#x2F;&#x2F;encore.dev</a>

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.

This minimalism fetish is grating. Guess what you need to &quot;just wants to get things done&quot;? Features. If you&#x27;re in luck, these are standard features, but if not, they will be exotic features that would never be built under that &quot;less is more&quot; philosophy. And it&#x27;s misleading to think that by only implementing the most popular core features, you&#x27;ll make the most users happy. Projects often <i>rely</i> 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.<p>A lot of highly popular contemporary open-source tools are feature-rich. Foobar, Winamp and VLC are all full of stuff you won&#x27;t need (but what this stuff is depends on you) and extendable. Notepad++ has perhaps the largest number of menu items I&#x27;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&#x27;s example (a sync tool), I&#x27;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.<p>A more reasonable rule is probably &quot;don&#x27;t include features that could be split off into a separate tool without loss of efficiency or functionality&quot;.

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

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.

Lots of this rings true, but i disagree about people only want to do the fun things.<p>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.

&gt; 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.<p>There&#x27;s one case I&#x27;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.

Bibliographic info for that sweet engraving is here:<p><a href="https:&#x2F;&#x2F;www.oldbookillustrations.com&#x2F;illustrations&#x2F;corliss-steam-engine&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.oldbookillustrations.com&#x2F;illustrations&#x2F;corliss-s...</a><p><a href="https:&#x2F;&#x2F;openlibrary.org&#x2F;books&#x2F;OL13511601M&#x2F;Appletons&#x27;_cyclopaedia_of_applied_mechanics" rel="nofollow">https:&#x2F;&#x2F;openlibrary.org&#x2F;books&#x2F;OL13511601M&#x2F;Appletons&#x27;_cyclopa...</a>

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.