Is Open Source entirely good? – Impulse #8

In my last post, I ended with a question: Is open source an entirely good thing? What are negative sides? It felt like a blindspot in my own thinking, which I uncovered while talking to Ursula Lagger. After doing some quick research, the answer is more complicated than I thought.

From a purely economic standpoint, open source is great. A Harvard-backed study estimated its value at a staggering $8.8 trillion. It is the critical, often invisible, infrastructure upon which modern society runs. Companies and economies depend on it.

But there is another side to that coin: the human cost. The system thrives on volunteer effort, but it’s a system that is exhausting the people who create it. While the benefits of working on open source projects are great, like accelerated skill development, best practices in code architecture, testing and collaboration, maintainer burnout is an existential risk to the ecosystem. In a recent survey, approximately 60% of open-source maintainers had considered quitting. Maintainers face a constant flood of demands from users with limited resources, insufficient (or no) compensation, and an unfortunate amount of interaction with toxic communities.

And what about us, the designers? For us this is a largely invisible opportunity. While our skills are needed, poor user experience and interface design are common barriers to open-source adoption, designers are almost entirely absent from these communities. Only about 1-3% of contributors are designers. This is likely due to structural barriers: the lack of designer-friendly tools, unfamiliar version control systems, and a developer-centric culture that often undervalues design contributions. A blindspot for the ecosystem, missing out on crucial expertise that could make open-source tools more accessible and user-friendly for everyone.

So, where does this leave me? This exploration hasn’t diminished my desire to contribute, but it has profoundly reshaped my understanding of the world I’m trying to enter. My goal to create a “Designer’s Guide to Open Source” now feels more important than ever. It’s not just about showing designers how to change a button or improve a workflow. It’s about preparing them to enter a complex ecosystem with their eyes open. It’s about encouraging contribution, but also advocating for a future where open source is as sustainable for its people as it is for the economies that depend on it.

Accompanying Links

Harvard Business School: Revealing the Economic Power of Open Source Software: https://d3.harvard.edu/revealing-value-the-economic-power-of-open-source-software/
A report on Open Source Maintainer Burnout: https://mirandaheath.website/static/oss_burnout_report_mh_25.pdf

Burnout in Open Source: A Structural Problem: https://opensourcepledge.com/blog/burnout-in-open-source-a-structural-problem-we-can-fix-together
The Internet Is Being Protected By Two Guys Named Steve (The Atlantic): https://www.theatlantic.com/technology/archive/2014/04/the-internet-is-being-protected-by-two-guys-named-steve/360766/

Ai was used to formulate this blogpost (Gemini + WisprFlow) an support with Research (Perplexity)

One on One Sessions – Impulse #7

Yesterday, I got to talk to two people, to get some feedback on my masters thesis. Ursula Lagger during the “Proseminar Master’s Thesis” class and Martin Kaltenbrunner during the “Final Crit” session. These discussions have changed, what I will/ want to du during the creation of my masters thesis.

For better understanding let me outline my thesis shortly. My thesis aims to explore and create a clear path for designers who want to contribute their skills to the world of open-source software. The initial plan was to research existing barriers and create a practical “workpiece” to demonstrate a viable contribution method. However, thanks to the input from my professors, the focus and form of that workpiece will change.

The first major insight came during my “Proseminar Master’s Thesis” class with Ursula Lagger. I was heavily focused on the parallels between open-source maintainers and my experience in social volunteering (in my scout group), looking at it through the lens of social science. She pointed out that while this comparison is interesting, it was pulling my thesis away from my actual field of study. How do people interact with the project and the code? How do they communicate and document their process? How do designers get involved? It was a sort of sobering clarification. I realised the core connection to interaction design was secondary and I will change my focus.

The second, and more disruptive, piece of feedback came from Martin Kaltenbrunner during my “Final Crit.” My plan was to create an open-source Figma plugin as a workpiece, to outline the whole process of the creation, maintenance and distribution of an Open Source project. He challenged this directly, arguing that building a plugin for a proprietary, closed-source tool like Figma is more of a simulation of open source rather than a genuine contribution to it. He made me question whether a project can be truly “open” if it’s fundamentally tied to a closed ecosystem.

I will probably move away from the Figma plugin idea. Instead, focus on contributing to an existing, truly open-source project. For example could address an UX issue I found in the Pi-hole project. This new approach feels more authentic and will serve as a much stronger, more “translatable” case study for the final outcome of my thesis: the guideline for other designers. This actually was a third, unifying piece of feedback from them. They suggested that the most valuable result would be a practical, reusable guideline for designers. The idea is to create a “manifesto” of sorts on how to get started and contribute to open source, something that goes beyond my personal project and can empower others.

The biggest shift in perspective probably came through Ursula Lagger, which revealed a blindspot in my own thinking. What are negative sides of Open Source Software? How could giving work away for free to be used by anyone change ones reputation? what impact could OS have on the day to day work of designers? In my next and final blog post, I plan to dive into this blindspot and investigate the other side of the open-source coin.

Ai was used to formulate this blogpost (Gemini + WisprFlow)

Installing a PiHole (Homelabbing_3) – Impulse #6

In my last homelabbing post, I talked about getting my server set up with Docker and hosting my first applications. A logical next step on my list was to tackle network-wide ad-blocking. As I hinted before, the time finally came to set up a PiHole. I was excited to improve my own network but also to get my hands on a piece of open-source software that is widely loved.

For those unfamiliar, PiHole works differently than an add blocking browser extension. Instead of scanning websites for ad-like code, it operates as a DNS sinkhole. In simple terms, when any device on your network tries to contact a server known for serving ads, the PiHole intercepts that request and sends back an empty response, so the ad never even loads. The biggest advantage? It works for everything on your network, your laptop, your phone, and even your Smart TV, where ad-blockers are often non-existent.

The setup process itself was a great hands-on experience. I used a tiny Raspberry Pi Zero that I got from my brother for christmas, flashed the operating system to an SD card, enabled SSH for remote access, and plugged it into my router. From there, running the single install command and watching it work its magic was incredibly satisfying. A few configuration changes on my router to direct all DNS traffic through the Pi, and it was up and running, protecting me from ads. ;D

Impact for my Masters Thesis

This is where this little project became a huge impulse for my thesis. While exploring the PiHole’s web dashboard, I stumbled upon a perfect, real-world UX issue. To block a domain, you add it to a blocklist. To allow one, you add it to an “allow list.” On the dashboard, the button to add a domain to the allow list is green.

As a designer, green signifies a positive action, like adding something while red signals a negative action, like deleting something. More than once, I found myself accidentally clicking the green “Allow” button when my actual intention was to block a domain. It’s a classic UX problem where the visual signifier conflicts with the user’s intent. For a developer, a green button for “allow” might make perfect sense, it’s the “good” list. But for a user managing blocklists, it creates confusion.

This was a firsthand example of a barrier a designer could help lower. I immediately thought, “This is open source, I should be able to fix this!” I wanted to change the button color, maybe add an icon, or just improve the layout. But then I hit another wall: the documentation on how to change interface elements wasn’t straightforward for a non-developer. I literally had no idea, where to start.

This entire experience perfectly encapsulates the core of my thesis. It’s not just about finding UX issues, but about the entire process: identifying a problem, understanding the contribution workflow, and finding the right documentation. My simple home lab project has given me a tangible case study, a real problem to solve, and a clear path to explore for my “Designer’s Guide to Open Source.” It’s the first step in moving from theory to a real, practical contribution.

Accompanying Links

Pi-hole official website – https://pi-hole.net/

Raspberry Pi Zero – https://www.raspberrypi.com/products/raspberry-pi-zero/

Ai was used to formulate this blogpost (Gemini + WisprFlow)

“Working in Public” Book – Impulse #5

I recently read “Working in Public” by Nadia Eghbal (now Asparouhova). I discovered the book during my literature research for the “Proseminar Master Thesis” class with Ursula Lagger and got it through an interlibrary loan. As a former developer-relations researcher at GitHub who interviewed hundreds of developers, she offers a fresh, insightful look at the world of open source that I want to share.

Before diving in, it’s important to understand the difference between “free” and “open source” software. The “free software” movement, started by Richard Stallman, is about freedom, not price. The term “open source” was created later to be more business-friendly, focusing on the practical benefits of shared code rather than the ethics of user freedom.

Eghbal’s book focuses on a key distinction in open source projects today: the size of their audience. She describes two models: the “bazaar,” with many contributors (like Linux), and the “stadium,” with a few maintainers and a huge audience of users. Most projects today are stadiums, often run by a tiny group of 1 to 5 developers.

Many projects follow a similar lifecycle. They often start in private, and once they go public, the creators are looking for engagement and feedback. As a project gets adopted, the role of the maintainers shifts from doing the actual code work to managing the project, the community, and the influx of casual contributors.

This leads to a major challenge: how are these projects financed? For many, the answer is they aren’t. The book details the different ways funding works. There are two main types of funders: institutions (like universities and companies) and individuals. Institutions often care about the quality of the code and their influence on the project’s roadmap. For individuals, the reason for funding is often personal; they might use the project daily and simply want to ensure it continues to exist.

The funding target also matters. Is the money going to a project or an individual? Funding a project makes it easier to manage the money transparently. Funding an individual offers more flexibility, as a developer might work on multiple projects. Asparouhova notes that companies tend to sponsor projects, while individuals tend to fund developers directly through platforms like Patreon or GitHub Sponsors.

This brings me to what I think is the most important takeaway from Eghbal’s work: we need to rethink how we value the different kinds of labor in open source. We tend to celebrate the “creator” – the person who has the initial brilliant idea. But what about the “maintainer”? The person who shows up day after day to fix bugs, answer questions, and keep the project alive. Their work is often less glamorous, but it’s no less critical.

If open source is to be sustainable in the long term, we need to find ways to support the maintainers. This could mean more funding, better tools, or simply a cultural shift in how we think about our responsibilities as users of open source.

As I continue my research, I’m left with a question: How can we, as designers and users, better support the maintainers of the open-source tools we rely on every day? I don’t have the answer yet, but it’s a question I’ll be exploring in the weeks to come.

Ai was used to formulate this blogpost (Gemini + WisprFlow)

First literature Research – Impulse #4

The last three blogposts where all about my intentions and the reasons for picking open source as the topic of my masters thesis, this one is about first steps, I took in researching about open source and how this influenced the next steps, I want to make.

During the “Proseminar Master Thesis” course, we were tasked, to gather some sources we could use for our thesis in the future. Two books and an article. Skimming through those texts really changed my view on open source. Especially the impact of UX work on open source projects interested me.

1. Working in Public

Reading Working in Public felt like having someone open a curtain. I always knew open source was built by volunteers, but the book made me understand just how much work, coordination, and emotional labor goes into maintaining a project. I was especially struck by the part that explained how most projects start small and private, and how everything changes once people begin to use them.
The sections on hidden costs and funding were honestly eye opening. Until now, I never really questioned how open-source creators manage to keep projects alive despite having almost no resources. This book made me more aware of why people burn out, why documentation suffers, and why newcomers have such a hard time finding their place.

2. Producing Open Source Software

Where Working in Public explained what is going on, Producing Open Source Software finally gave me how. This book was far more structured, and honestly much easier to navigate. For the first time, I read concrete advice on where design can fit into an OSS workflow, especially the points about improving documentation, lowering the “activation energy,” and funding dedicated UX roles.
The most influential part for me was the idea that newcomers should write beginner tutorials. That simple thought made me reflect on my own homelabbing struggles: of course the docs feel hard, because they’re written by experts.
This shifted my thinking from “What UX problem should I research?” to “Maybe the onboarding experience of designers in OSS is the problem.”

3. Untold Stories

The third text, Untold Stories, finally backed many of my assumptions with research. UX professionals do help OSS projects. Their contributions are valuable. And still, hardly any of them participate.
The paper helped me understand why: the culture, the tools, the developer-first mindset.
What surprised me most was how differently UX people write issue reports: more factual, more user-centered, more structured. It made me think that maybe designers don’t need to force themselves into OSS spaces—they just need to show the value of this way of communicating.
It also strengthened my idea that UX needs its own “space” within OSS—something that current platforms don’t provide.

Accompanying Links

Link to the book “Working in Public” (sadly no free download): https://press.stripe.com/working-in-public

Link to the book “Producing Open Source Software”, which is free to download: https://www.producingoss.com

Link to the article “Untold Stories”: https://dl.acm.org/doi/10.1145/3706599.3720063

Ai was used to formulate this blogpost (ChatGPT)

Voluntary Service & Open Source- Impulse #3

Continuing from the last blogposts, where I talked about what got me interested in open source as a master’s thesis topic: homelabbing. In this post, I want to talk about an intrinsic motivation, that kept me moving towards this.

Voluntary work is part of my day to day life. Since 2014, I have been part of the scouts, first as a child now as a guide. Once a week I run meet-ups for children form 7 to 10 years old, where we go out into the forest, play and teach them to be come a valuable part of society. Doing work like this takes much more time, than one would think, there is planning those 2 hour sessions, preparing before the kids come and cleaning up after they leave. There are weekend camps and a big summer camp to organise, the groups home needs to be tidy and there even is a course a scout leader must take, learning about communication and pedagogy. I give a huge part of my free time to the scout movement, and all for no pay.

In addition to big voluntary movements like the scouts, there are small communities like the “UX Graz” Community, which organise a meet up for people interested in UX design, every third Tuesday of the month. Everything is organised and run by volunteers. Every meet up is held at a different company, which provides the location, food and drinks, and there are two parts in every meet up, first there are some talks and second networking. For people attending it is completely free. Free food, free drinks, free knowledge transfer and free new contacts. (I have recently joined the organising team swell, so this is my second voluntary work.)

In my mind, there are a lot of parallels between voluntary work and open source. A small amount of people does work or creates something, that benefits a lot of others. And the work these people do is often overlooked. They act in the background often earning nothing more than respect and thanks from others. Especially in these times, it is hard t have a job, that doesn’t pay you money, next to your regular day job. Due to different reasons most people cant’t afford to work for free, still there are a bunch of people who do.

I hope to find a reason for people to work for free. In my opinion voluntary work provides a lot to society. Although sometimes I feel like the work volunteers do is under appreciated, especially youth organisations. Although to be fair, open source doesn’t mean free and open source projects aren’t always maintained by volunteers who aren’t getting paid. What drives people to give away their product for free? How can the value of voluntary work be communicated? Looking into the psychological and social aspect of people doing work just for the benefit of others, is something I would want to get into more.

Accompanying Links

A link to the UX Graz Meetup: https://www.meetup.com/uxgraz/

A link to the website of the Austrian scout movement: https://ppoe.at

Hosting Applications (Homelabbing_2) – Impulse #2

In my last blog post I wrote about my first steps in homelabbing, to clarify in homelabbing you try to setup a home server environment to run services, test and learn new stuff. Some examples: Host a cloud service, a picture backup service, a home NAS (Network Attached Storage), your own streaming service or even a Minecraft server. I set up a “home server” an old laptop got it a new operating system and installed the first services.

After this first success, I felt ready to dive deeper. To really host a service, that I can use, maybe even outside of my home network. And the first thing, that came to my mind was a Minecraft server. My cousin had done it, other friends had done it, so it can’t be that hard. And it really isn’t. The documentation is good, all in all it’s just installing java & the basic server run file. I just had one issue, which was exposing a port to the internet, which I could solve after a while of searching through forums. (I ended up finding the answer in the docs, just not where I looked.)

Now, I had used the terminal, I had a service running, why not set up something that I can use in a more productive way? And this one, didn’t go so well. See for a lot of the services most people run on their homelab you need a separate software for them to run properly, most of the time that is Docker. In short, Docker solves the “It works on my machine…” problem, a lot of new software has. (Here is a Network Chuck tutorial explaining Docker in more detail: https://youtu.be/eGz9DS-aIeY?si=aSPVoBCwRwZ6zaLs) It basically creates the perfect environment to run a certain piece of software. And just getting that to work, took me a while, reading documentation, forums, watching video tutorials.

After I had setup Docker and it was running properly, I decided to install a Remote Desktop application, so I could make changes to my home server from where ever I wanted, without having to use the old laptop to do so. I planned to hook it up to my home network and leave it running, without having to open it up to make changes. Through a Reddit post I discovered RustDesk, an open source remote access software, which can be self hosted through Docker. And for the first time, installing a new service just worked. The Docs were easy to follow and in less than an hour, I had RustDesk running.

After this first success I really wanted to have a service running, that would provide a benefit to my day to day life. Three different ones really caught my eye: PiHole, a network wide ad-blocking service, Immich, a Google Photos like picture backup cloud and n8n, a patching tool similar to Max that let’s you create Ai supported automations. (I provided Links to the projects below)

Sadly It was not all fun and games. Like all good homelabbing projects I ran into another problem, which had put this whole experience to a hold. Everything I had done until now ran through the W-Lan of my apartment, which is suboptimal, it clogs up the WiFi for other mobile devices and is slower, compared to a wired connection. Since I planned to put the server somewhere in the apartment and never move it again, I wanted to hook it up immediately. This lead to the laptop not booting, so I couldn’t do anything while it was hooked up to the network, but it would work fine when I unplugged it.

Impact for my Masters Thesis

Thinking back now, when I tried to set up Docker, this actually was my first encounter with a big problem in open source: Bad newcomer onboarding and difficult documentation. As I would find out later, during deepening my research in open source, this is also one of the areas that experts see the most use for UX work, creating an easy to understand onboarding and easy to read documentation. It’s a hit or miss. Sometimes it takes hours to troubleshoot a problem and reading through forum posts, to find the solution, that works for you.

What still stuck with me this whole time, thinking about open source, was the thought of coming into a new area or hobby and trying to solve a problem I don’t truly understand. I have used open source software before, I read docs and learned a lot, still finding a research question or a problem to solve is hard. I guess I need to dive deeper into this whole field to truly understand it. Everything I thought about felt strange, a new person coming in and trying to solve a problem that they read about in some forum or book. This lead me more into the direction of documenting, how to contribute as a designer in the first place or how to run/ start an open source project, since I really like the way of providing a product for others to use and change, best case for free.

Accompanying Links

Here are some links to the different services I mentioned im the blog post:

https://rustdesk.com

https://minecraft.wiki/w/Tutorial:Setting_up_a_Java_Edition_server

https://n8n.io

https://immich.app

https://www.docker.com

https://pi-hole.net

Reinstalling (Homelabbing_1) – Impulse #1

Quite a while ago I found an old laptop at my parent’s place. A very old machine, I used back when I was like 15 years old. Not very flashy but at that time a good device to do what I needed to do, which was school work and playing Minecraft. At that time I was really into home automation, doing things myself, creating my own NAS (Network Attached Storage) or hosting other applications. So after getting my old Laptop, I started to test some stuff. The first thing, I noticed was that the laptop was very slow. I don’t know what 15 year old me did to that thing but it sure wasn’t the best for the hardware.

After doing a little research, on how to breathe life into an old laptop, I stumbled across Linux. For those who don’t know, Linux is a light weight open source, mostly free, operating system. Just like Windows or MacOS. And let me tell you, choosing the right Linux distribution to run on my machine was another rabbit hole, since there are so many. There are ones optimised for hacking, or to look like MacOS, or to be very light weight (ArchLinux). In the end I decided to use the most common Linux “Distro” (short for distribution): Ubuntu. Which is supposed to give me a similar experience to windows and is one of the most widely used Distros. (Which comes in handy, when trying to troubleshoot anything, since someone most likely already fixed that same problem.)

Next steps included, going through old data and clearing out old junk, erasing all data and installing a fresh installation of Ubuntu. And I got to say getting to this point too a while, but after the laptop booted into the home screen of Ubuntu it felt great! But what to do now? One of the “simplest” thing I could think of was trying to connect the laptops storage to my home network, so I could use the old guys storage capacity to exchange data from one device to another, without plugging in an USB stick, or saving backups of very important data. To accomplish this, I used Samba (another open source project), which let me expose a folder to my network. Setting this up took a lot of trail and error, as well as a lot of terminal commands. But now I can get data from my MacBook to my Windows PC without attaching and detaching anything.

Starting this project was a lot of fun. A bunch of new things to learn and new possibilities arise. After this first success I got a bunch of other ideas which I could now host on my own, a cloud service, a Minecraft server or a google photos like application to save and share pictures.

Impact for my Masters Thesis

But what does this have to do with my masters thesis? A lot of the software used when creating a home lab is free and open source. Additionally the freedom to host your own services for free, because someone created free software for you to use, is great! Nevertheless it is a fun project, to get into computers and hosting one’s own cloud service feels great and has a lot of advantages (and disadvantages).

All those possibilities got me thinking, why and how do people create software used by thousands and millions of users? What drives open source projects? How are they financed? So in short this was the start of my interest in open source and the reason, why I want to dive deeper into this topic in my masters thesis. I am sure, there is more to uncover, to try out and to learn.

Accompanying Links

If you start to build your home lab, there is a bunch of stuff you need to know about and Network Chuck provides an amazing overview of most relevant topics. From explaining Linux to n8n (an Ai automation software) to hosting your own NAS. The videos are easy to follow and beginner friendly, in other words the perfect start for newcomers.
Here is a link top his YouTube channel: https://www.youtube.com/networkchuck

When trying to do anything on Linux you will need to use the terminal. Installing apps, bluetooth doesn’t work, advanced settings. open the terminal. As a beginner, I didn’t understand what I was writing in this text input. So I used this website: https://explainshell.com/# (another open source project), that explains every command that is put into the terminal.

The last link I want to share is the website of samba, the software I used to open up a folder to my home network. As they say on the website: “Samba is an important component to seamlessly integrate Linux/Unix Servers and Desktops into Active Directory environments.”
https://www.samba.org

Evaluation of a Master’s thesis

Autor: Matthias Müller, BSc
Titel: Applying Service Design on Free Open Source Software (FOSS)
Erscheinungsjahr: 2017
Hochschule: Graz University of Technology
Master: Software Development and Business Management
Quelle: https://repository.tugraz.at/publications/yq1qq-qwe76

This master’s thesis takes a closer look at how open-source software projects actually work. While open-source tools are built “by users, for users” and have changed the tech world in many ways, their success often depends on more than good code. The author uses service design methods to explore the Austrian open source project “Catrobat”, mapping everyone involved, their roles, and how they work together. The goal is to find out what helps or holds back open-source projects and how better collaboration and understanding can lead to more innovation long-term success.

Presentation quality 

Overall, the master’s is well made, the layout is simple yet fitting, since the layout itself probably wasn’t part of the scope. Simple paragraphs, some graphics and pictures, highlighted quotes, nothing special, although you could find some gaps in the text due to the full justification. Long, bloated sentences and swollen language make the text difficult to read. But the arguments made follow a logically form, from explaining the open-source context to applying service design tools.

Degree of innovation & independence

What stood out to me is how service design is connected to the world of open-source software, since any design practices are usually hard to be implemented into open source projects. The work shows a high level of independence, especially in how the author adapts existing design tools to fit the unique dynamics of Catrobat. Although making assumptions for the whole world of open source might be a bit farfetched, since open source projects can be very different, not only in size but number of users, supporters or funders, distribution channels and much more. Meaning this is a great case study but doesn’t really contribute to making the open source more design friendly.

Organization and structure 

The thesis is well structures, although sometimes hard to understand. The author is very thorough, service design & Catrobat are both very well defined and explained. Before using a service design tool, the author explains the reason for using it first, explains the process, shows the results and their conclusion in the end. The flow of the work seems natural, and additionally the usage of graphics and pictures, as well as bullet points really help to clarify.

Communication 

Like I have said before, the language is hard to understand, or in other words very academic. However, this might just be due to my background being in design and not more science driven studies, like computer science or information technology. In the eyes of a student of the technical university of Graz, the tone might be common.

Scope 

The topic is handled with an appropriate level of detail overall, although personally I would have pot emphasis on different topics, as the author did. Catrobat is explained in a lot of detail, while user research or testing of proposed improvements fell short, although those are key elements of servicer design.

Accuracy and attention to detail 

Citations are well made, if they are taken word by word, they are visually different from the rest of the text. Footnotes as well as inline citations are flawless and all figures are accurately described. I also couldn’t find any grammar or spelling mistakes, luckily writing software like microsoft word gets better at catching those mistakes.

Literature 

The literature review is solid, with relevant sources from design, service research, and technology studies. It combines classic design theory with more recent publications about open collaboration. The references are well integrated and show that the author understands the academic conversation around the topic

My personal reason to pick out a master’s thesis like this one was to get a better grasp on open source in general, since I want to write my thesis about the same topic, although with a different scope. I used this exercise to get more insight into the opinions of non designers working on open source software. But as I pointed out, grasping the topic and the conclusion was hard, due to me not being able to understand and comprehend the way sentences were written.

Disclaimer:
This blog post was supported by AI (ChatGPT) to help with structuring and phrasing.