Wednesday, September 5, 2018

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:

Wednesday, July 25, 2018

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.

Wednesday, July 11, 2018

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.

Tuesday, July 10, 2018

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.

Wednesday, June 27, 2018

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.

Friday, February 2, 2018

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.

Wednesday, January 31, 2018

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 RVMrbenv, 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.

Governance on demand

I have talked about the Spectrum of Open Source Governance Models  before. After rereading Nadia Eghbal's excellent post Governance with...