An Interview with Michael Schumacher, GIMP administrator

This is the second of a series of interviews of various people surrounding GIMP development and community. See also the interview of Mitch, GIMP maintainer

GIMP is made not only by hard-core developers but also through the hard work of many less technically-inclined contributors.
Michael Schumacher, aka Schumaml, is a great example of an important core contributor who has been with the project for over 10 years. Mostly known as the project administrator, nowadays he takes care of everything but programming: administrative tasks, management, PR, support…

Schumaml was recently named the maintainer of the 2.8 branch, the stable version of GIMP which only receives bugfixes, showing that it does not require a developer to manage important roles successfully.

This interview was held on Saturday, February 4, 2017, at about 12:27 AM in front of a fireplace and after a day of hacking at Wilber Week. With us were several team members, including Debarshi Ray (Rishi (R)), Øyvind Kolås (pippin (P)) and Simon Budig who also asked questions.

Schumaml, the tie-bearing GIMP office manager
Schumaml, GIMP administrator (photo by antenne used by permission (cba))

Jehan: Hello Michael. You are the GIMP administrator, at least that’s what everybody says.

Schumaml: That’s what everybody says, yes.

J: How would you describe your contribution to the GIMP project?

S: I don’t do much coding. It’s just that so many people — from my perspective — do coding on GIMP already and have a better grasp of the source code and how it is made up. So I don’t think I can contribute much in that regard. I try to do administrative stuff like handling the monetary aspect of the project such as telling GNOME that we need money for events like Wilber Week or for LGM reimbursements…
I also care about the bug reports we have. I try to have them categorized, have a proper status, make sure that they get replies, and that we don’t leave a bug report unattended for a long time.
Also, I have administrative privileges on the GIMP web server, on mailing lists, and… what else. Do I forget anything? That’s about it, yeah.

I’ve been called the tie-wearing GIMP office manager and I even got a t-shirt with a printed tie and a “TWOM” label, because I’ve actually been wearing a proper shirt (made to measure) at one GIMP meeting during the Libre Graphics Meeting 2012 in Vienna.

Schumaml, the tie-wearing GIMP office manager
Schumaml, the tie-wearing GIMP office manager (photo by houz (cba)).

J: How long have you been contributing?

S: I think I started somewhere between 2001 and 2004. The first contributions were probably getting GIMP buildable on MSYS, the minimal GNU build system on the Windows platform. Because I was annoyed that there were only GIMP builds for releases and not for every commit in between.

J: Was it like nightly builds?

S: No it was not like nightly builds. I just wanted to be able to have a current build for the MS Windows platform and also made on the MS Windows platform, so that I could build on my Windows system I was using at the time. Just to be able to follow GIMP development more closely than using a build someone made for a development release.

J: So you mostly use GIMP on Windows?

S: Back more than 10 years ago, I did use Windows exclusively. So basically, back then I had done the porting of GIMP to the Windows platform.

J: Do you use GIMP?

S: I use GIMP. Not as much as many other people but I use it to test many things of GIMP itself. I use it to edit photos I make. I don’t publish many of the images because when I’m editing them, I print them or I use them for some documentation work, so it goes to a customer. I even still use it on MS Windows, but now my main platform is Linux.

J: What kind of job do you do?

S: I’m working for a company that used to be a part of Siemens, which had been carved out by now. We are selling communication systems – in the past, you would have called these telephony systems. Nowadays this stuff is called “Communication Enabled Business Processes”, like everything which has to do with communication: calling someone or texting someone or exchanging chats or whatever. We are providing the software, the service, and the consulting.

J: Why do you contribute to GIMP?

S: It started due to pure selfishness: being able to have the most current GIMP available to me.

Since then, a lot has changed: I believe in Free Software. I believe software should be available for everyone for every purpose. GIMP is a Free Software project. Around the time I got hooked up with GIMP, I also got hooked up with Wikipedia, which follows the same approach towards knowledge. I feel like — yeah well — I’m contributing to something that helps a lot of people all over the world. I think that’s a good thing. GIMP happens to be the the first major project I contributed to, and I like it. It’s also in-line with the topics I specialized in at university: image synthesis, image manipulation. It kind of seemed like a logical extension.

Schumaml, the tie-bearing GIMP office manager
Not the Formula One driver. (Photo by Pat David (cba))

Rishi: What do you think of Michael Schumacher?

S: (laughs) The formula one driver?

R: Yeah.

S: First thing, you know about his current condition, like probably still in the coma. I hope that he will get better. He probably won’t make it to his former self but at least to a state allowing him to live in a somewhat decent way.
He got famous when I was in the so-called German “Gymnasium” (part of secondary education). It was a bit of an annoyance then – I got the same nickname – “Schumi” – as he had. I didn’t follow his career too closely, but knew about every race he won because I would be congratulated at school.

pippin: Have you ever made use of sharing the name?

S: No I haven’t. It got me an interview opportunity with a locale radio station because they were calling all people who had the name “Michael Schumacher” and they were asking them “How hard does this affect your personal life? Has it ever affected you?“. Once, I almost had an appointment canceled because someone thought I was mocking them, but that was the only incident ever.

I’ve never used it. I’ve never abused it. Nowadays, after the end of his professional racing career, it basically didn’t matter anymore.

P: Any controversial theme you wish to be asked?

S: Like the fact that I would like to kill spammers? (Maintain several mailing lists, one forum, be a recipient for “can we haz ads on, plz?“, and you’ll know what I mean)

Simon: Not very controversial.

J: What do you want to see in GIMP?

S: Feature-wise, I’m quite OK with what GIMP is right now. I have to admit that some of the current stuff in the GIMP development version is still above my head – for example, I have no real concept yet of the difference between compositing and blending. Learning that it was 2 different things was quite useful. I hope that we can get the documentation of GIMP up-to-speed in time.

I’m more concerned about the project management. As in: how do we decide what new features go into GIMP, how they get into GIMP, and what GIMP development will look like. Particularly post-2.10. You can see it yourself: Right now, our release cycles are much too long. Even the fact that we have actual release cycles is probably bad. If you have a look at services like Twitter or similar, they are constantly releasing. They just push new features out to the people and there is a constant review “this is working, this is not working“. With our long release cycles, users get surprised by “Oh this does not work as it used to. Why have they changed it?“.

The project is still a bit old-fashioned in regard to releases. We are trailing current development models. “Development models” is the term I use because I’m not sure how to refer to this. I’m intrigued by the idea of having stable branches with continuously added new features, but I’m not quite sure if I want 2.10 to be constantly evolving. I would prefer to have 2.12. That’s details.

J: How do you see GIMP in 20 years?

S: First thing: in 20 years, I’ll be 60 (laughs). So I’m not even sure how I see myself at that point. I very much would like to still be part of the project in 20 years. I would still like to be able to see it as an image manipulation program. One of the major Free Software ones. I have no idea at all what it will look like (laughs) because there is so much that can change. Especially in the user interaction. How people interact with software might be the defining factor for how applications will look in 20 years.

J: What’s the feature you are really waiting for?

S: The feature I’m really waiting for… It’s not a feature of painting or image manipulation. It’s about organization. This thing we want to do, Plug-in or Resource Registry 2.0. Properly built and really managed. The thing we talked so much about, have so many great ideas, but always seem to lack the time to do. This is the feature I would like to see.

J: Do you contribute under influence?

S: Yeah, have a look at the 2.8.20 NEWS file. At the typos, which I totally didn’t notice. So now I prefer to not contribute under influence.

J: Indeed you are now the maintainer of the 2.8 branch, or at least the releaser. If not mistaken, you took care of 2.8.18 and 2.8.20 releases. What can you say about this?

S: I guess I should start at why I am doing more 2.8 releases. As I explained before, I’m not interested in coding that much but more engaged in user support and maintenance. Approximately one month before the release of 2.8.18, we had received a report about a security issue in the XCF loading code. It was fixed quickly, for both the development and 2.8 branches, but there was no plan to do a 2.8 release. We have instructions for this, and mitch replied “Just do it!” when I asked about it.

It still felt like flying blind. Had I done the version changes – to 2.8.18, and afterwards advancing to 2.8.19 – correctly? Was the tarball made correctly? Would it build on any other system than mine? It did, but I had still missed two action: the release tag is supposed to be signed (i.e. git tag -s) and the GNOME translations teams should be notified about planned releases with a string freeze be put in place until the release to make it easy for them to complete translations. 2.8.20 was much better prepared and even had an extra long string freeze. I had planned to do it in October 2016, but had to delay it to February 2017, during Wilber Week.

Releasing is definitely something you want to do right, and this means taking a moment of uninterrupted time to do it. My approach towards bug handling has changed a bit, too. I pay much more attention to bugs with attached patches, and try to apply and test those (we really neglected to do this) in order to get them into a stable release.

J: This was a good interview.

S: Thank you for doing it.

Bookmark the permalink.

Comments are closed.