55,041,902 Lines of Code

I did some exploration on KDE's code base. It's amazing what you can find when you have almost 30 years of public history in git.

In doing so I ran some statistics on KDE's core software. That core is relatively well-defined, even over the years. It's the libraries (Frameworks), the desktop (Plasma), and the standard applications shipped together on a regular release schedule (Gear). Of course there are other fine applications in Extragear and elsewhere, but I didn't look at them for now.

In 2009 I did an analysis of KDE's sources and found 4,273,291 lines of code. So I was curious to see where we are today. The numbers are not 100% comparable, because the shape of KDE's core software has changed a bit, but when you look at what is in git (omitting graphics, translations, and other non-code files) you find 8,173,148 lines of code.

But wait, didn't the title say 55,041,902 lines of code?

Yes, when you look at the history, there is more. There is churn, code gets added, code gets modified, code gets deleted. It evolves. So behind every line of code which is shipped today, there are about 7 lines of code which have been written, changed, deleted. This is what you find in git.

So 55 million lines of code have been written to arrive at 8 million lines of code today. They represent progress, learning, and adaptation to a changing world. You see life there.

The most amazing part for me is actually not the code itself, but that there are thousands of people behind this code who have worked together for decades to continuously improve KDE's software. That's the real story.

P.S. Take the numbers with a grain of salt. They are based on a couple of assumptions and influenced by quirks of tools and history. This is not science, it's the report of a hobby code historian.

Invest in your identity

I have 30 years of documented history on the web and in my personal recordings. That defines very well who I am, what I do, how I see the world, and how people see me. I worked on that. Sometimes consciously, sometimes as a side effect of my job, my side projects, my community work. Now that AI agents make it easy to use this kind of material, I have a base to anchor them, to build on what I did before and accelerate what I do, still staying me.

If you are starting now, you won't have this body of material to anchor your agents. So do spend some time building this corpus of what is genuinely you. Don't let an AI generate what you are. Write yourself, publish, think through your thoughts, give presentations. Small things are fine. They will accumulate over time.

Of course, tools will shape part of your identity. I used to do my presentations with xfig, printed on overhead projector slides. This was painful, but it shaped quite a bit how I worked and how the result looked. So it is part of my identity. The technical constraints did influence how I spoke, how I presented. It also shaped what I presented, because there was a bias toward what I could show with the tools available to me.

This won't be different with AI. It will shape who you are. But be aware, and make sure that there is a signal from the human in there. It's ok if it's imperfect, if it's a bit weird. It's ok if it's different. But make sure it's yours.

Shape that signal. That's you. That's your identity.

Personal Digital Sovereignty

We feel how dependencies can hurt

There is a lot of talk about digital sovereignty. Being able to act as a state or as a company is obviously important. But there are real dependencies, and given the current geopolitical dynamics, there are real risks. Unfortunately, there are no easy answers. Digital sovereignty matters, but so do stability, efficiency, and innovation. Fortunately, there are options and some good examples of how to deal with it. I collected some material in an awesome list on digital sovereignty.

While it is complex at the state level, it is merely complicated at the personal level. Reaching something like personal digital sovereignty is possible. If you are informed about the technical landscape, you probably already have a good intuition about it. You feel the pain of having to stop using a service because the provider decided to discontinue it without you having a say. You can decide whether it feels right to upload your personal diary to a server in a jurisdiction you do not control.

Free Software provides a path

There is a clear path to personal digital sovereignty. The goal is nicely expressed in KDE's mission: "A world in which everyone has control over their digital life and enjoys freedom and privacy." The path is provided by Free Software. The freedoms to use, study, share, and improve give you exactly what you need to be in control.

For software you run yourself, this works well. Running Free Software on your personal computer gives you control. It feels good. It becomes more complicated when you use services you do not and cannot run yourself. The software freedoms do not transfer easily. There are a lot of services, which are mostly based on Free Software, but only the service providers enjoy the freedoms, not their users. I have written about this before when working on my Fair Web Services project.

A good testament to personal digital sovereignty is the Blue Angel for software. Its focus on resource and energy efficiency is one side of responsible software use. Maybe even more important is its emphasis on user autonomy: being able to use software without ads being forced on you, being able to choose what to install, and having transparency about what you run. These are the ingredients of personal digital sovereignty.

Finding the balance

Freedom is one side, but convenience is another. Sometimes it is easier to just use something a vendor has invested heavily in providing, even if you pay with your data and some independence. It is also a question of where you spend your time: do you build something for yourself, or do you use something that already exists? And sometimes it is about the limits what you can do yourself. Powerful tools can give you leverage so you can focus on your actual mission.

So it is also about compromise. One very important aspect for me is that I am still able to choose. That is the core of personal digital sovereignty. Sovereignty does not mean doing everything yourself. It means preserving the ability to leave, even if you choose not to.

Federated services make it easy to migrate. For git, for example, it does not matter so much where the server is or who runs it, because switching is as simple as changing the remote. For a proprietary note-taking service, this looks different. You may need special exports, format conversions, and you might lose functionality because it is not based on open standards. Choose your dependencies wisely.

It is important to remember that dependencies are not bad per se. We know this from Free Software. We know what it feels like to stand on the shoulders of giants. We rely on the collective strength of a global community. It is not about rejecting all dependencies or doing everything on your own. It is about creating alternatives and shaping an ecosystem based on openness, so that we can choose and act on our own terms.

My personal stack

I am quite happy with my personal stack, which gives me the control I need. My 12-year-old desktop runs Linux and KDE. I pay to host my own email, Nextcloud, and git services. One project I particularly like is GitJournal, which gives me control over my note-taking across all my devices. This covers the core of my computing needs, with my family, my friends, and what I decide to keep private.

To stay connected to the wider world, there is no way around being present on large networks. GitHub and LinkedIn are the compromises that give me reach without requiring me to abandon all my principles. I would not publish my writing only on LinkedIn, though, because I want to own what I produce.

AI is a difficult question right now. It is easy to switch between services, and with rapid development it is changing quickly what the best choice is. And it can provide tremendous leverage. So it remains an evolving compromise. An ideal future would offer open models powerful enough to serve your needs and that you can run locally.

Building digital sovereignty

On a personal level, you can decide for yourself. There are limitations, and you will have to build on the environment available to you. But there are alternatives, and you can choose to build your personal digital sovereignty.

At the corporate and state level, it is more difficult. The systems are more intertwined, but the pain of dependencies you cannot control and the risks of others making decisions for you are just as real. Alternatives exist there as well, often the same ones available on a personal level. It can be worth taking bold decisions.

Digital sovereignty at the state level is about national security. At the personal level, it is about personal freedom. Free Software provides a powerful path to maintaining control over our digital lives.

I am not arguing for tools. I am arguing for agency.

What does it mean to write in 2026?

I've been writing for something like 50 years now. I started by scribbling letters on paper as a child because I was fascinated that these expressed meaning. I wrote a lot for school, for university, for work, and privately. I wrote letters, emails, posts on social media, articles, papers, documentation, diaries, opinion pieces, and presentations. I've been writing my blog for more than 20 years.

Writing always has been a way for me to connect to the people, to the community, around me, communicating with my tribe. It also has always been a way to express, refine and archive my thoughts, a bit like building a memory of insights. It also has been a way to record some of my personal history and the history of the projects I'm involved with.

My writing has changed over the last couple of years. I'm writing less publicly and more focused on specific projects. It feels like it has become less personal and more utilitarian.

Part of this is that the Internet has lost a good part of its strength as a neutral platform to reach the world. For a long time I knew where to reach the people I wanted to address and had control about my content and how it was distributed. Nowadays social media platforms act as distributors, but we are prey to their algorithms. So while publishing content is still simple, it's much harder to get it to your audience without compromising to the mechanisms which make the algorithms tick.

Another part is the disrupting advance of AI writing capabilities. While I have relied on humans to give me feedback in the past, to get into a conversation on the topics of my posts to refine the thoughts in them, now there is this all-powerful-seeming assistant in my editor who is eager to take over those roles. And it would even write for me in my own style. So what's the value of writing in 2026? Is it even worth bothering with trying to express your thoughts in writing, when a machine can produce content which looks the same, much faster and in much larger quantity? What does this do to readers, do they still care about what I would write?

My feeling is that it's still worth to put in effort to create genuine, trustworthy, truthful writing. The format, the tools, the channels might change, but the values don't. The challenge will be to figure out how to create a signal which transports these values.

I have always liked the format and style of a blog, as a stream of thoughts, coming from a personal perspective, but focused on topics of relevance to others. I enjoy reading this from others and I enjoy writing in this style. And I don't have to rely on a platform I don't control, but can use my own.

So it looks like this blog won't go away, but will channel my thoughts in 2026 as well.

Team Profile

What makes a great team? One important factor is that you have a balanced set of skills and personalities in the team. A team which only consists of leaders won't get much work done. A team which only consists of workers will not work into the right direction. So how can you identify the right balance and combination of people?

One answer is the Team Member Profile Test. It's a set of questions which team members answer. They are evaluated to give a result indicating which type of team member the person is and where it lies in the spectrum of possible types.

There are two dimension which are considered there, how much team members are oriented towards tasks and how much they are oriented towards people. This can be visualized in a Results Chart.

Here is an example:

You can see five segments:

• The center (5,5) is the "worker" who has a set of balanced of attributes, no extremes. These team members are extremely important because they tend to just get stuff done.
• The top left (9,1) is the "expert" who is focused on the task and its details but doesn't consider people that much. You need these to get the depth of work which is necessary to create great results.
• The bottom right (1,9) is the "facilitator" who is something like the soul of the team, focused on social interactions and supports the team in creating great results.
• The top right (9,9) is the "leader" who is strong on task and people and is giving direction to the team. You need these but you don't want to have more than one or two in a team otherwise there are conflicts of leadership.
• The bottom left (1,1) is the "submarine" who floats along and tries to stay invisible. Not strong on any account. You don't want these in your team.

The test can provide some insight into the balance of the team. You want to have all but the submarine covered with an emphasis on the workers.

How does your team look like on this diagram?

Twenty-Five Years of KDE

It's KDE's birthday today. Twenty-five years ago Matthias Ettrich called for programmers to create a GUI for end users of Linux. They came and did. I wrote about the first Twenty Years of KDE five years ago. What I wrote there is still true, but there is more.

The table where KDE was founded

KDE started with tremendous ambition and momentum. Creating this unified graphical user interface, this integrated desktop for Linux, this vision drove hundreds and hundreds of amazing people to put together a massive amount of code, the desktop and tons of applications to cover all needs. And they succeeded, KDE's desktop represents the state of the art for many years now, on par with the best alternatives out there.

Over the years, with a growing community, the focus shifted. KDE was not only about this integrated desktop anymore, it turned into an umbrella for dedicated sub-communities working on specific parts and applications. The community got bigger and more diverse and created applications such as Kontact, Kate, Okular, Krita, GCompris or Kdenlive. All of them are at the top of their category.

KDE Plasma 5.22

I use KDE software for more than two decades now. I read my mail with KMail, I operate my shell with Konsole, I edit my texts with Kate, I manage my desktop with Plasma. It's special for software to stand this test of time. KDE's software is stable, it's durable, it's reliable, it's carefully adapted to deal with changes in its environment, so that it stays fresh and familiar at the same time. Some may remember the heat we got for breaking things with KDE 4.0. That was thirteen years ago. It has been much smoother sailing since then. So maybe this is what I learned to appreciate the most over the last years: KDE creates sustainable software.

The same is true for the community. The community always was KDE's finest features for me and, as I know, for many others as well. I met many very good friends there, and it's still great to also meet new people. People join, people leave, people stay around. It's a very healthy mix. KDE creates sustainable community.

Akademy 2021 group photo by Akademy Team (CC-BY)

There is a very strong feeling which keeps this together, the feeling of doing meaningful things together. It's an experience which is tremendously strong in KDE, but also in many other Free Software projects. Being free and empowered to do these changes you want to see in the software you use. Having people around you who support you, praise and criticise your work, and work with you on a shared purpose. This can be an incredibly strong source of motivation and satisfaction and happiness. It definitely has been for me.

Thanks, KDE, for a wonderful twenty-five years, and all the best for many more to come.

11 takeaways from a year of online conferences

I love going to conferences. It's how I learn, meet people, get inspiration, share my work, and have fun. The last conference I went to physically was FOSS Backstage in March 2020. It was great. I talked about Inner Source, met great people, had great discussions.

That was one year ago. Conferences got cancelled or went virtual. I have been to a lot of virtual conferences since then. It's great, attending doesn't require travel, fees went down, with a few clicks you could join any conference on the planet. Sometimes it was attending one session and realizing that it wasn't for me, sometimes it meant spending days in a different time zone.

Of course it's not the same, it's different. So what have I taken away from a year of online conferences?

Ease of access makes a huge difference - I have been to huge conferences who would have been in the US such as KubeCon but also to small local ones I probably wouldn't even have noticed such as the OpenBike conference. If they would have been physical events I wouldn't have been there. They all gave me something of value.

Emulating a physical conference is meh - There are so many systems which try to stick close to the format of a physical conference, with virtual lobbies, virtual booths, virtual conference rooms. In the end they all felt hollow. You visit booths and get all the emails but none of the stickers and no real social interaction.

Live talks are ace - You might think it doesn't matter if a talk is recorded or live. You just watch a video, aren't you? But it's noticeable if somebody is speaking live, there is a different level of energy. For a speaker it might be nice to answer questions during their own talk but it is a distraction and these side talks would be impolite during a physical talk for a reason.

You need more time - It's tempting, back to back talks, only seconds to switch rooms. But there needs to be chatter, there needs to be space to relax. And without the energy you get from a physical group of people it's more exhausting to focus on a conference hours in a row. So while in theory you could do more in an online format, in practice you should aim for less.

Treat talks as broadcasts - Without the limits of physical spaces you can go bigger, you can broadcast. No need to impose artificial limits. And broadcasting videos of people speaking is a well understood art. It's what TV is doing all the time, it's what YouTubers and streamers are doing. Embrace it, tap into the tools and the experience of people who are doing this already. re:publica 2020 did that in a very interesting way.

Manage chat - You need a way for people to chat, but it can quickly get our of control. Big rooms with hundreds of participants amplify the signal of individuals too much. So the best conferences were those who managed that carefully, providing extra sessions for tracks or individual talks, providing breakout rooms, have moderators to guide people around, have a quick way to create your own channels for specific conversations in a natural way. Also give room to the introverts, who might not want to chat with many people at the same time.

Have fun going down the technology rabbit hole - Naturally you need some technology to participate in online conferences. It should not be required to go crazy on that, but some good equipment is really helpful, and it can be fun to go deep on some of that. So have fun exploring fancy microphones, green screens, OBS, light and camera arrangements, DIY teleprompters, etc. And learn from the streamers, they have figured out a lot of that.

Don't save on moderators - Online formats need more guidance. That can't come from the speakers alone. It's worth a lot to have good and present moderators. They keep conversations going, handle technical issues, create atmosphere and much more. You probably need more of that then you assume.

Continue experimenting with the social bits - The stuff which is going on besides the talks, that's what usually makes or breaks a conference. The social bits. These are harder to replicate in an online format than anything else, and they need most creativity as direct translation from offline formats doesn't work well. So keep experimenting. Do things such as a pub quiz, a virtual hallway track, a cocktail challenge, spreadsheet parties, speed dating, music tracks, walk & talk etc. A special shout-out to Work Adventure here. This has been one of the most effective tools I have seen to give some social feeling to a virtual conference.

Authenticity beats perfection -  Polished videos of speakers who rehearsed and cut their videos. That's marketing. It results in these videos which get you 23 clicks on YouTube. They look like you have seen them before. A speaker who has their roommate walking by, or who are struggling with the video situation etc, that's reality. People who have something to say will still bring across their point and engage the audience. Authenticity is a big part of this.

Support the organizers - It's tough. Business broke away for many conference organizers. It's fantastic that many took up the challenge to deal with the situation and become creative. But they need support. Organizing conferences is hard and if you are constrained in the way we have been during the last year it's particular hard. Support the organizers by participating, speaking, sponsoring, and what else you can do.

So a few weeks ago it was FOSS Backstage time again. This time as a virtual event. It was a great experience again. A fantastic lineup of speakers which probably wouldn't have come together at a physical event. Some creative ways to get people together and inspired such as the pirate themed track or the virtual lounge. And lots of insights, conversations, and things to learn.

I'm looking forward to what still is to come in terms of virtual events. I'm sure we haven't seen all what is possible there. Keep on experimenting.

Governance on demand

I have talked about the Spectrum of Open Source Governance Models before. After rereading Nadia Eghbal's excellent post Governance without foundations I feel tempted to add one more: Governance on demand.

Why that?

Nadia suggests a theory in the last footnote of her post, "that projects only need to define governance at the first sign of conflict". Intuitively, this makes immediate sense. We have all seen the projects which seem to work very fine without any thoughts about governance, and we also have seen those projects where attempts to set up formal governance have brought things to a halt instead of serving the project. So doing it at the last responsible point in time, when you actually need it, sounds like a very attractive model.

Being able to add governance on demand needs a high level of awareness and reflection. It also needs a culture which is open to the idea of governance, has the means to facilitate discussions about it, and is able to come to a conclusion. It is the point where you have to "decide to decide".

This is not easy, especially in the context of a conflict. It can be paralysing. Making decisions without having defined structures, without having precedence, takes responsibility and courage. Maybe not everybody will go along with it. You don't know because you haven't done it before.

One model which seems to be a quite natural outcome of such a "we need governance, now" situation, is the "benevolent dictator". When conflict arises, the founder or another exposed person steps in and takes a decision. This sets a trajectory for the project, which might be right or not. It depends on the project, on the people, on the environment.

Another model which comes naturally is to follow the "those who do the work decide" principle. This adds local, high context governance. It has to be underpinned by common values and a common sense of direction, though. Otherwise it will fail to solve the kind of conflicts where active people seem to stand against each other.

If you have a strong culture, it might appear you don't need governance. If you have shared values, if you have a common mission, if people learn by imitating healthy behavior from others, then it's easy to take decisions and to preempt conflicts. This could also be called a state of implicit governance, because it is there, but it's not formulated.

If you have a strong culture, then you are also prepared to add governance on demand. This can become necessary because of growth, a changing environment,  or other factors which can't be addressed by existing intuition.

From this point of view: Build culture first and governance will follow.

These are my thoughts. I would be more than happy to hear about your thoughts as well.

Foot note: In some way "governance on demand" is not a governance model in itself, but more a meta model. It doesn't tell how the governance regarding the project then has to look like but only answers a part of the question how to get there. It is in the nature of governance models to also cover this meta level, though. Maybe "governance on demand" is more a governance element than a model in itself. It governs the evolution of governance models.

Beautiful GitHub labels with Terraform

Managing issues is part of the daily life of most software projects. Reacting to bug reports, feature requests, pull requests, tracking what's going on and where to put attention, all that is usually handled in the bug or issue tracker of the project's choice.

On GitHub there are the GitHub issues, and they have become quite powerful over time. Just recently GitHub added the capability to show related issues, pin issues to repositories and to move them between repositories.

One important tool to manage issues on GitHub are labels, those nicely colored badges you can add to issues to get a better overview, to filter lists and queries, or to build further automation such as the presentation of good first issues to people new to the project.

If you have a lot of labels it tends to become a bit of effort to manage them well, especially if you want to keep colors consistent and descriptions up to date. It becomes even more effort when you try to do so across different repositories. We have all seen the psychedelic potpourri of colorful labels which tends to happen when you use labels generously.

Last year I saw Mitchell Hashimoto's excellent talk about anything as code at the Open Source Datacenter Conference in Berlin. He showed there how to use Terraform to manage infrastructure as code beyond the typical management of computing infrastructure such as servers or networks. He showed how to use it for more administrative tasks such as managing teams on GitHub.

This is a great approach because it replaces clicking around in a user interface by a more programming-like approach of maintaining configurations, preferably version controlled, and applying the same rules on them as on code. So you can do pull requests, review changes, have the history of what happened in git, run tests and other automation easily, etc.

The GitHub provider for Terraform also handles labels so I thought I would give it a try to manage labels as code. Directly doing this in the Terraform configuration is possible but it's a bit cumbersome and limited in what you can do with the data in this format. So I decided to put the data into a good old YAML file and writing a bit of Python code to deal with it.

The result is beautiful-labels, a small tool to manage GitHub labels from a YAML description via Terraform. It scans your repository for existing labels and their data, creates a YAML description from it, and then provides you the tools to turn it into a Terraform configuration.

Terraform is great in handling the state of things in the cloud, it takes care of operating the API in an effective way, figuring out what needs to be updated, and gives the user control, for example by providing a dry run which tells what would change without applying the changes yet. This is all quite convenient and powerful.

One thing beautiful-labels is supposed to make easy is the management of label colors. In addition to the convenience of managing them in YAML instead of having to use the UI, it also adds the option to generate an overview of the labels as SVG, nicely grouped in categories. This helps in grouping things together using colors and generally can augment documentation about how you intend labels to be used.

The tool is in an early state but it works. I use it to manage the labels in the inqlude repository on GitHub.

You could add another step of automation by letting CI run Terraform on commits to the YAML file. Maybe something to try for the future. As managing labels is not something you usually do on a daily basis, some manual step might also be good enough.

One caveat with labels is that GitHub uses the name of the label as identifier. That usually works great but can be a bit tricky when changing the name of a label. For this case I recommend to do it in the GitHub UI for now.

There are some other approaches how to do this kind of stuff. One of them is labeler which is a nice tool written in Go to manage labels from a YAML description. It directly operates the GitHub API. The advantage is that it's self-contained but it lacks the power of Terraform in terms of state management. Another is Zach Dunn's post "How we organize GitHub issue: A simple styleguide for tagging" which introduces the notion of color-coded categories.

It's wonderful when pieces come together, such as the GitHub API, Terraform, YAML, git, and people writing open source code around that. They result in a way to beautifully manage labels without having to put in too much effort.

If you have feedback or input please don't hesitate to drop me a line. I would be happy if beautiful-labels would be useful for you as well. Let me know how it goes. :-)

My open source career

When I started doing free software in 1999, I came for the technology. I wanted to practice my C++ skills. I was fascinated by developing graphical user interfaces with Qt. I wanted to scratch my itch of organizing my life digitally. I started to work on KOrganizer.

I stayed for the community. I stayed for the friends I met, for the amazing people I work with, for the people using my software. There is this feeling, when you go to an event such as a conference, and you meet the people you have worked with over the internet for the first time in person, and it feels like meeting old friends. No matter how diverse their backgrounds are, there is something which holds the community together. This is why I’m still there.

And while I didn’t plan it, doing free software became my career. I did free software because I was curious, because I could apply and hone my skills, because I could learn, because there were real challenges, because I could shape what I did and how I did it, because I could work in a brilliant team, because I got direct feedback from other contributors and from people using my software, because what I did mattered to others. Putting all that together made the ideal job, and it turned out that this is something companies need and pay for.

My learning experience in the free software community went beyond technology. I also learned a lot about people, about how they work together, about organization, about leadership. I became a member of the board of KDE e.V., the foundation behind the KDE community, and this was the ideal place to learn about a lot of the non-technical aspects.

I’m an engineering manager and distinguished engineer at SUSE today. My free software work was essential in developing the technical skills which make me a distinguished engineer and the leadership skills which make me a manager. I’m still contributing to free software. It’s part of my job. It still is a way to learn, and it keeps me grounded.

I have written and talked about this before, and somehow I feel this comes together nicely in three key points which summarize what I consider to be most important:

• You have to start somewhere: My first patch
• You need a community to support you: 15 years of KDE
• Don’t do it for the money: Don’t sell free software cheap

I'm going to Akademy, again

A little bit less than a month and I will be at Akademy again, KDE's annual conference. This is the place where you can meet one of the most amazing open source communities. To me it's kind of my home community. This is where I have learned a lot about open source, where I contributed tons of code and other work, where I met a lot of awesome friends. I have been to most Akademy events, including the first KDE conference "Kastle" in 2003. But I missed the one last year. I'm more than happy to be back this year in Vienna on August 11.

Akademy will start with the conference on the weekend, August 11-12. I was in the program committee this year and I think we have put together an exciting program. You will see what's going on in KDE, what the community is doing on their goals of privacy, community onboarding, and productivity, hear about the activities of KDE e.V., get to know some of the students who work as part of one of the mentoring programs such as the Google Summer of Code, and much more.

It's a special honor to me to present the Akademy Awards this year together with my fellow award winners from last year. It was hard to choose because there are so many people who do great stuff in KDE. But we have identified a set of people who definitely deserve this prize. Join us at the award ceremony to find out who they are.

Being at Akademy is always special. It's such an amazing group of people hold together by a common idea, culture, and passion. You could never hire such a fantastic group. So I feel lucky that I got and took the opportunity to work with many of these people over the years.

It's also very rewarding to see new people join the community. Akademy always has this special mix of KDE dinosaurs, the young fresh people who just joined, and everything in between. The mentoring KDE does with great care and enthusiasm pays off, with interest.

Vienna is calling. I'll quickly answer the call. See you there.

Freedom and Fairness on the Web

There is an ongoing debate about freedom and fairness on the web. I'm coming from the free and open source software community. From this perspective it's very clear that the freedoms to use, share, and modify software are the cornerstones of sustainable software development. They create the common base on which we can all build and unleash the value of software which is said to eat the world. And the world seems to more and more agree to that.

But how does this look like with software we don't run ourselves, with software which is provided as a service? How does this apply to Facebook, to Google, to Salesforce, to all the others which run web services? The question of freedom becomes much more complicated there because software is not distributed so the means how free and open source software became successful don't apply anymore.

The scandal around data from Facebook being abused shows that there are new moral questions. The European General Data Protection Regulation has brought wide attention to the question of privacy in the context of web services. The sale of GitHub to Microsoft has stirred discussions in the open source community which relies a lot on GitHub as kind of a home for open source software. What does that mean to the freedoms of users, the freedoms of people?

I have talked about the topic of freedom and web services a lot and one result is the Fair Web Services project which is supposed to give some definitions how freedom and fairness can be preserved in a world of software services. It's an ongoing project and I hope we can create a specification for what a fair web service is as a result.

I would like to invite you to follow this project and the discussions around this topic by subscribing to the weekly Fair Web Services Newsletter I maintain for about a year now. Look at the archive to get some history and sign up to get the latest posts fresh to your inbox.

The opportunities we have with the web are mind-boggling. We can do a lot of great things there. Let's make sure we make use of these opportunities in a responsible way.

Mapping Open Source Governance Models

I already posted the Seven Lessons of Open Source Governance from my talk at FOSS Backstage. Another part of the talk was about a project to map open source governance models. The idea is to have a machine-readable collection of data about how different projects implement their governance and a web page showing that as an overview. This should help with learning from what others have done and provide a resource for further analysis. It's meant as a map, not a navigation system. You still will have to think about what is the right thing to do for your project.

The project is up on GitHub right now. For each project there is a YAML file collecting data such as project name, founding date, links to web sites, governance documents, statistics, or maintainer lists. It's interesting to look into the different implementations of governance there. There is a lot of good material, especially if you look at the mature and well-established foundations such as The Apache Foundation or the Eclipse Foundation. I'm also looking into syncing with some other sources which have similar data such as Choose A Foundation or Wikidata.

The web site is minimalistic now. We'll have to see for what proves to be useful and adapt it to serve these needs. Having access to the data of different projects is useful but maybe it also would be useful to have a list of code of conducts, a comparison of organisation types, or other overview pages.

If you would like to contribute some data about the governance on an open source project which is not listed there or you have more details about one which is already listed please don't hesitate to contribute. Create a pull request or an open an issue and I'll get the information added.

This is a nice small fun project. SUSE Hack Week gives me a bit of time to work on it. If you would like to join, please get in touch.

Seven Lessons of Open Source Governance

At the FOSS Backstage conference two weeks ago I talked about the spectrum of open source governance models. Watch the video for all the details. One key part was the seven lessons I learned during my now almost twenty years of experience working in open source projects:

Be conscious about governance, not formal

Governance is important. Your project does have a governance model even if you don't think about it or if you don't write down the rules. It governs how your project will work and how people will be able to collaborate. It will also define a big part of your culture. You don't want to leave these things to chance. So be conscious about governance.

That doesn't mean that you have to write rules and policies for everything. Often a healthy culture where people learn by following the example of the leaders and other members of the community works well. It might be tempting to create a formal structure to cover all kind of possible scenarios. But creating and maintaining policies is an expensive process. Don't be formal where you are not sure it's needed.

Spell out the fundamentals

There are some non-negotiables which have to be spelled out and written down. The license is the most important one for an open source project. You also might want to spell out some other aspects which define your culture such as values of your community or a code of conduct.

Learn from others

There is a huge number of open source projects out there. They cover many different use cases, types of technology, and flavors of community. Learn from them. Most things have already been invented.

Don't create foundations

You will know when to ignore this advice but generally don't create foundations. It's a lot of effort and needs ongoing work to keep up with the responsibilities and obligations you create by that.

There is a number of umbrella organizations your project can join. This gives most of the benefits of having an own organization such as being able to handle money but with much less work.

Beware of growth

Different stages of an open source project need different types of governance. Growth will change the dynamics of your project. Be conscious and watch out for changes in the project which require changes in the governance.

Also think about if you want to have growth at all and what kind of growth. Having many users is great but it also comes with responsibilities and expectations.

Keep your sanity

Your are working in the open. A lot of what you do is public. People will contact you and will want things from you. This can be overwhelming, especially if your project is successful. Find ways how you keep your sanity, how to avoid being stressed out by your open source work, how to keep a healthy balance between your open source work and the other parts of your life.

Be kind

That might be the most important advice. Be kind. Be respectful. Be aware of cultural differences. Make sure that people feel well and are happy in your community.

It's software development. It's all about people after all.

Pair programming with git

Git is great. It took the crown of version control systems in just a few years. Baked into the git model is that each commit has a committer and one author. Ofen this is the same person. What if there is more than one author for a commit? This is the case with pair programming or with mob programming or with any other way of collaboration where code is produced by more than one person. I talked about this at the git-merge conference last year. There are some workarounds but there is no native support in git yet.

It seems that the predominant convention to express multi-authorship in git commits is to add a Co-authored-by entry in the commit message as a so-called trailer. This adds more flexibility than trying to tweak the author and committer fields and is quite widely accepted, especially by the git community.

I'm happy that GitHub added support for the Co-authored-by convention now. It makes multi-authorship more visible. That's a good thing.

I did some work on adding native support for multiple authors in git. The direct approach of allowing more than one author field might be too intrusive due to the many possible side effects. But the Co-authored-by trailer is still a good solution. I have an unfinished patch to add some native support for that in git. It does need some more work, though.

Contributing to git is an interesting experience. The git mailing list is the central place. The contribution workflow is well-documented. It's good that Junio as maintainer has spelled out how he reviews patches and what that means for contributors. And it's definitely fun to work on a self-contained C project.

I'm looking forward to more multi-author support in git and GitHub. Pair-programming is a great model, and properly reflecting in the commit logs what happened when the code was written is the right thing to do.

Ruby on openSUSE

Ruby is a wonderful programming language. Every year in December as a kind of Christmas present there is a new release. It's great to be on a language which is kept up to date but it comes with the challenge to manage multiple Ruby versions. There are a couple of solutions around such as RVM, rbenv, or chruby but they all have their drawbacks.

What would a Linux distribution do? At openSUSE, we package all the versions in the Build Service. We also package many gems but this is an effort which is sort of futile given the huge and growing number of gems and their versions. But you do reliably get the Ruby interpreter and gem tool as openSUSE package. To not create conflicts all the executables are suffixed with the Ruby version. That allows for parallel installation of multiple Ruby versions. It also works for all the executables installed through gems. The drawback is that you don't get the executable names you would expect because of the additional suffix.

So how does the ideal solution look like? We want the distribution maintained interpreter packages, the co-installability of multiple Ruby versions, the native executable names, and the full power of gem.

There is a nice solution to that. It looks like this:

Native executable names can be achieved by creating symbolic links in the bin directory of the user for the tools which come with the Ruby package: ruby, gem, erb, and rake.

Setting the GEMHOME environment variable to a directory in the user's home nicely isolates installation of gems. Parallel versions are handled by gem anyway. You don't need root to install gems and you can easily get rid of an installation if needed.

By setting `install: --no-format-executable` in your .gemrc you get executables with their native names in the GEMHOME directory. So you only have to set the PATH environment variable to let your shell pick them up so that you can call bundle, rspec, etc as it's meant to be.

All this needs a little bit of setup work. To make this easier we have created a tool for openSUSE to manage this for you. It's called orr.

With orr you can just do `orr install 2.4` and it installs the required packages, creates the links, and configures the environment variables so that you can use Ruby 2.4 right away. That works for any other version as well of course.

This setup brings you the best of both worlds, Ruby and openSUSE. Enjoy. And provide feedback.

SUSE Hack Week 15

Back in February the fifteenth SUSE Hack Week took place. As always this was a week of free hacking, to learn, to innovate, to collaborate, and to have a lot of fun. I didn't have the full time, so I worked on a couple of small things and a few projects I maintain. I did want to summarize that, so here you go.

The first project remained unfinished. I wanted to fill out Tim Urban's Life Calendar (you might have seen that on his excellent blog "Wait But Why"), but realized that it's not trivial to map dates to weeks in your life. So I wrote a small tool to calculate that, stopped after I had a failing test and had a rough feeling for how to put the dots on the life calendar.

The second project was something I always wanted to do, implement Conway's Game of Life. I had once started an implementation in 68000 assembler on the Amiga many years ago, but never finished it. Technology has advanced, so I decided to do at as ASCII pixel art. Who needs high resolution? The result turned out to be a bit more generic, as a command line tool to manipulate pixel matrices stored in text files, the Pixelist. While I was at it, I also implemented Langton's Ant and a simulation of diffusion limited aggregation.

GivenFilesystem is a Ruby gem I maintain for writing unit tests dealing with files on disk. It's quite convenient, if you test code, which writes files on disk and you want to have a well-defined environment without side effects for testing this code. There were some open pull requests. I reviewed and merged them and released given_filesystem 0.2.0.

I already wrote about Inqlude, where I used Hack Week to finally publish the new Inqlude web site, which is based on the work Nanduni did during last year's Google Summer of Code. It's a great improvement. I also did some cleanup work, including reviewing the open issues. So we have a nice roadmap now. There is some interesting work to do. People who want to help with that are always welcome.

Trollolo is another side project I work on from time to time. We use it for supporting our Scrum work flows at SUSE in Trello, such as generating burndown charts. I didn't get around to write code, but I consolidated some of the ideas floating around and put them into issues. This also is a nice opportunity, if you want to have some fun with writing a bit of Ruby code for a small project. Issues are up for takers.

Finally I worked a bit on the next iteration of my attempt to make git support multiple authors. This would make life with git in a pair programming situation much nicer. Based on the feedback I got on my first iteration and at the Git Merge conference, I started to work on a version which puts the data into the trailers of the commit messages. This is less intrusive and with a bit of tooling it achieves similar results as the version which worked directly on the commit headers. I have something working, but it needs a rework of the trailer handling code. I'll continue to work on that when I find some more time to do that.

New and improved Inqlude web site

During last year's Summer of Code I had the honor of mentoring Nanduni Indeewaree Nimalsiri. She worked on Inqlude, the comprehensive archive of third party Qt libraries, improving the tooling to create a better structured web site with additional features such as categorization by topic. She did an excellent job with it and all of her code ended up on the master branch. But we hadn't yet made the switch to change the default layout of the web site to fully take advantage of all her work. As part of SUSE's 15th Hack Week, which is taking place this week, I took some time to change that, put up some finishing touches, and switch the Inqlude web site to the new layout. So here we are. I proudly present the new improved home page of Inqlude.

All libraries have additional meta data now to group them by a number of curated topics. You can see the topics in the navigation bar on the left and use them to navigate Inqlude by categories. The listing shows more information on first view, such as the supported platforms, to make it easier to find libraries according to your criteria without having to navigate between different pages. The presentation in general is cleaner now, and some usability testing has shown that the page works better now than before. In addition to the visible changes, Nanduni has also done quite a bit of improvements under the hood, including better automated testing. I'm proud of what we have achieved there.

It always has been a privilege for me to act as mentor as part of Google's Summer of Code or other programs. This is one of the most rewarding parts of working in free software communities, to see how new people learn and grow, especially if they decide to stay involved after the program has ended and become valuable members of the community for the long term. Being able to help with that I feel is one of the most satisfying investments of your time in the community.

Twenty Years of KDE

One afternoon twenty years ago Matthias Ettrich and Martin Konold sat at a stone table in the cafeteria of the university Tübingen and talked computers. They talked Linux and they talked desktop. They talked about making Linux accessible to everyone. This was the moment where KDE was born. This afternoon they walked away with a mission. Matthias went on to write the call to action to found the KDE project, and Martin to create the very first KDE mailing list kde@fiwi02.wiwi.uni-tuebingen.de.

On October 14th 1996 the famous announcement arrived on the newsgroups comp.os.linux.development.apps, comp.os.linux.misc, and de.comp.os.linux.misc:

    New Project: Kool Desktop Environment. Programmers wanted!

The new project quickly attracted a group of enthusiastic developers and they pushed out code with a frentic pace. kdelibs-0.0.1 was released in November, containing the first classes KConfig and KApplication. In May 1997 the young project presented at the Linux-Kongress in Würzburg. In August Kalle Dalheimer published the famous article about KDE in the German computer magazine c't which attracted a whole generation of KDE developers to the project. On Jul 12th 1998 KDE 1.0 was done and released. The community had not only implemented a friendly face for Linux but also a bunch of applications while going, including a full web browser.

KDE did hundreds more releases over the years, continuously improving and maintaining the growing number of applications and amount of code. The community grew. It started to do annual conferences such as Akademy or the Desktop Summits and focused developer sprints such as the Osnabrück or the Randa meetings. KDE e.V., the organization behind KDE, which was founded as partner for the KDE Free Qt Foundation, grew with the community to be the corner stone of the organizational structure of KDE, using German association law as its secret superpower (read more about this in the book "20 Years of KDE: Past, Present and Future").

Millions and millions of people used KDE software over the years. Thousands of people contributed. KDE made appearances in Hollywood movies, it was subject of theses and scientific studies, and it won many awards. KDE's founder, Matthias Ettrich even received the German Federal Cross of Merit. The timeline of twenty years of KDE is an impressive demonstration of what Free Software is able to achieve.

Akademy 2014 group photo by Martin Holec (CC-BY)

KDE also was a breeding ground. Many people started their careers there. Hundreds of students went through mentoring programs such as the Summer of Code or the Season of KDE. Whole projects emerged from KDE, such as ownCloud and its sibling NextCloud, Kolab, or KHTML, which turned into WebKit and then Blink, powering most of web browsers on this planet today.

Today Linux has reached world domination in various, sometimes surprising, ways. KDE has contributed its share to that. With Plasma it provides a slick and powerful desktop which does make Linux accessible to everyone. This mission has been accomplished. But there is more. Following KDE's vision of bringing freedom to people's digital life there are amazing projects exploring new areas through Free Software, be it an application such as Krita to bring freedom to digital painters, or a project such as WikiToLearn to create collaborative text books for education. When KDE people meet you can feel the enthusiasm, the openness, and the commitment to change the world to the better just as in the days of the beginning.

I joined KDE in 1999 with my first patch to KOrganizer. I wrote a lot of code, maintained and founded applications, served on the board of KDE e.V. for nine years. Most importantly I found a lot of friends. Neither my personal nor my professional life would be what it is today without KDE. I owe a lot to this community. Thank you for the last twenty years.