Problems in FLOSS Projects #1 - Feature: Burden or Boon?

Welcome

Welcome to part one of a series I’ve decided to create on this blog, called “Problems in FLOSS Projects”. I intend this series to be a number of relatively short posts, each one investigating an interesting topic or issue I’ve seen or faced, mostly within the Jellyfin project, but also in FLOSS self-hosted software in general. Some are technical, some are managerial, some are neither, but all are things that I’ve thought about and want to write down for the benefit of others who may not have thought of these ideas, or who have and didn’t have a name, or even for whom these are constant struggles and who would like validation that they’re not alone. I don’t intend these posts to have a concrete point or thesis, but just to share a musing or observation, interspersed with my own advice, for others to see. Some of these could have been thought-of-but-unwritten responses to Reddit posts, extensions of chat discussions, or general observations I made, really anthing that didn’t “fit” another medium. And some that did and I’m just lifting here for posterity.

As you can tell historically I haven’t updated this blog much, but I hope by creating a little series like this without a formal goal, it will encourage me to write more. I hope you enjoy.

Who uses your software?

Generally speaking, it seems that administrators of self-hosted software tend to fall into to main camps: Users and Admins. Now, yes of course anyone running self-hosted software is generally an “admin”, but I mean something specific with these terms, so bear with me. When I use the words “User” and “Admin” capitalized later in this piece, I mean these two definitions.

Users want software that “works”, that is to say, fulfills a function. They want self-contained software that can be installed quickly and easily, and that will provide them some functionality. Then, they use the software, often only tweaking or updating it when they feel like it, when they hit a bug, or when a really exciting new feature comes along. Users will generally tolerate small bugs, but big bugs, especially big breaking bugs, tend to turn them right off of a piece of software.

Admins want software that is “interesting”, that is to say, provides them joy in and of itself, either to set up, to learn, to discover functionality, or just in general, to tinker. They will definitely use the software as a User does, but for them the joy is in the journey, not the destination, and they’ll probably run a nightly or upgrade every release within hours just for the fun of being on the bleeding edge. Admins also tend to tolerate much more and much bigger bugs than Users will, some even reaching true “Hacker” level and helping write the software.

Now, if you’ve read those two descriptions and thought “Well, sometimes I’m a User, and sometimes I’m an Admin, what a false dichotomy!”, you would be right. In fact, for a lot of the things I self-host myself, I certainly fall more into “User” than “Admin”. I want it to just sit there and work so I never have to think about it. Of course, with other things, like Jellyfin, I’m an Admin (when my users won’t notice). And while you would probably say that almost every first-time self-hoster falls squarely into the User category, for those of us with more experience, professional or otherwise, the line absolutely blurs significantly.

But the real point of these descriptions is less about individuals as a whole, and more about the conceptual space each type represents, like the comparison between Introversion and Extroversion. Every user of your software is going to fall somewhere in these two camps - practical vs. interesting, stable vs. bleeding-edge - though not always in the same place for every piece of software, or even on different days with the same software.

However, we can use these two models to help us figure out a deeper issue: is a feature going to be a Burden, or a Boon?

Burden or Boon?

Every feature you add to a project/product is going to add more conceptual baggage to the software. A really interesting portrayal of this can be found in UX designer and musician/composer Tantacrul’s “Music Software & Bad Interface Design” series [1]. In this particular episode, speaking about Sibelius and its Ribbon design, he discusses at length the usefulness of a (good) Ribbon UI in helping solve a major problem that Microsoft originally, and Sibelius later, found with their software: there were just too many features to anyone to find them all. The Ribbon UI was a solution to this; we can debate at length about how successful it was, but it illustrates a real problem with software design.

When you add features, those features have to both serve a purpose, and be accessible to your users.

This seems obvious. After all, why would anyone add a feature if it served no purpose and wasn’t accessible to the user?

The problem with self-hosted server software is that you have to take into account your user concepts when asking this question. For instance, let’s take a very real feature request for Jellyfin: support for SSO.

SSO, or Single-Sign-On, is functionality that allows an end user to authenticate to a single captive portal-like page once, and then be seamlessly logged in to multiple services at once. Think how a random site can log you in with your Facebook account, immediately taking you in a small popup to a Facebook page where you confirm access, and then promptly log you in. This is SSO.

SSO is a really useful feature for a lot of software, especially as a self-hosting admin who runs many services. You can automate authentication and hand it off to another piece of software. You can centralize authentication, as well as ensure that one badly-behaved application cannot leak credentials.

But here’s the rub: SSO is an Admin feature. The majority, perhaps even the vast majority, of people running self-hosted software don’t care about SSO functionality. They don’t know the internals of HTTP basic authentication versus application authentication, they don’t know what LDAP is, and they certainly don’t know what Kubernetes is. These are all extremely advanced features. Most self-hosted admins are, especially at the start, Users. This feature is, not only useless to them, but if your only authentication is via SSO plugins, you’re going to lose them very quickly.

You must think about whether a feature you add is a Boon to both Users and Admins, or a burden to one group or the other. And it cuts both ways. For instance, a very simple authentication scheme might be all that a User wants. But now the Admin is frustrated, because his more advanced use-case necessitates some extensions to that authentication (for instance, SSO, or more commonly just plain LDAP support), and the software doesn’t provide it.

The sliding scale of User-Friendly

This is a topic I could (and maybe will) write a whole blog post on, but “user friendly” when describing software is almost always a misnomer. User-friendliness is a sliding scale. Something that is friendly for a beginner can easily become tedious for an advanced user, and something that an advanced user sees as conceptually basic can be an unimaginable learning curve for a new user. This is something every software must face.

But the difference with self-hosted software is that you don’t just use have “users” in the traditional sense, you also have the two conceptual spaces for the administrator as well. If the software has a huge learning curve during initial setup, it will attract Admins but not Users, and if your software is super easy to set up but lacks any advanced features, you will attract plenty of Users but Admins will quickly become frustrated (or, hopefully, help you hack, if you’re open to it).

So what is the point of all this? Besides me putting to words these thoughts?

Well, my advice to any aspiring manager/designer/creator of a piece of self-hosted software is this: make sure you think about these things, especially when designing new features. Who does your feature help, Users or Admins? Who is your feature a burden on, Users or Admins, or neither? By asking yourself these questions, and understanding the two types of self-hosted administrators, you can help design software that everyone will like. And when adding features to your project, thinking about which group the feature is targeted at can help you decide how to integrate the feature, whether or not to make it mandatory, and how and where to document it.

I’ve seen many cases where these concerns aren’t thought of, and the result is almost always subpar software. Either Users are unhappy, or Admins are unhappy, and the software suffers for it. Users build community, Admins push the envelope. And worst of all, if both groups are unhappy, no one will use your software at all! Which sometimes, fine, it scratched your itch. But to make something that many people use, that is useful to not just the author, is generally the goal of FLOSS, and taking these issues into account will help you realize that goal. Because we all want FLOSS and self-hosting to take over the world.