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.

Is my OpenStack ready for Cloud Foundry?

This year's first Cloud Foundry Summit took place in Santa Clara at the end of May. Beyhan Veli from SAP and I gave a presentation about the Cloud Foundry OpenStack Validator, a new tool we developed as one of the results of our collaboration with SAP on the BOSH OpenStack Cloud Provider Interface project.

The validator gives operators of OpenStack systems a simple tool at hand to check if their OpenStack installation is ready to run Cloud Foundry. OpenStack comes with a lot of options and flexibility, and not all configurations are equally suitable to run Cloud Foundry. The requirements are documented and there are instructions how to manually check them, but it requires quite some expert knowledge to get everything right.

The validator is supposed to encapsulate the expert knowledge and instructions. It checks all requirements automatically and gives operators a report with the information if requirements are met or what they need to change. Cloud Foundry makes it simple for developers to deploy their applications. We try to capture the same spirit of simplicity for operators of Cloud Foundry on OpenStack.

We are running a test pipeline for the continuous integration of the BOSH Cloud Provider Interface for OpenStack which is used in Cloud Foundry. This runs on SUSE OpenStack Cloud. It works smoothly now, but while getting there it would have been great to have the validator to have a simple check of the setup without having to go through manual deployment and testing and finding issues with the setup late in the process. We captured some of this experience in code, and it is much easier with the validator now.

The architecture of the validator is quite simple. It uses the same interfaces as BOSH and Cloud Foundry to access the underlying cloud infrastructure, so it closely resembles what is happening in production. Most of this goes through the Cloud Provider Interface. Some lower level checks directly use the OpenStack APIs.

Tests are written in RSpec, which gives a nice concise way to describe and run the checks which are run by the validator. The validator is provided as a standalone tool, which can simply be run on the command line and will print out a report with what checks it has run, if they have succeeded, and what needs to be done if something is missing. In the end it will answer the question, if my OpenStack is ready to run Cloud Foundry, and this hopefully will be a big green yes.

There is ongoing work to improve the validator, to add more checks, and make it more complete in checking the requirements of the full stack, from OpenStack, through the Cloud Provider Interface, to Cloud Foundry. This will be a continuous improvement process with new checks being added as they are found to be relevant when setting up OpenStack based Cloud Foundry installations. To make this easier and also allow to add custom checks, there likely will be some kind of plugin interface to add new checks to the validator.

As it is using the abstract Cloud Provider Interface it might also be interesting to use the validator with other cloud infrastructures, and we need to evaluate how it plays with other approaches of validating cloud infrastructure. The project is open, the code is published as open source, and we are welcoming feedback and discussions about its future direction.

It was the first time I attended a Cloud Foundry Summit, and I really enjoyed the event. It covered a broad range of topics, inspiration, user experience, deep dive into the technical foundation, science fiction, and much more. Good information, great inspiration, and meeting lots of awesome people, it was an excellent event.

The next summit will be in Frankfurt, Germany, in September. I'm looking forward to see you there.

This blog entry was first published on the SUSE blog.