Community Spotlight on Heiko Rupp

Open source as second nature to this project leader

Image by : 

opensource.com

x

Get the newsletter

Join the 85,000 open source advocates who receive our giveaway alerts and article roundups.

Some people have been working on open source projects for so long, and collaborating as a process and method for getting work done, that it's just second nature and kind of odd for them to talk about what it's like.

Heiko Rupp, a contributor to Opensource.com and Principal Software Engineer and Project Lead for the RHQ project at Red Hat, shares with us in this Community Spotlight the hardware he wishes were more open in his life. Heiko also gives a glimpse into his day-to-day on the RHQ-Project, an enterprise management solution for JBoss middleware projects and other server-side applications.

The Basics

  • Name: Heiko Rupp
  • Username: pilhuhn
  • Location: Stuttgart, Germany
  • Occupation: Principal Software Engineer and Project Lead for the RHQ project, Red Hat
  • Open source connection: Usenet administrator (read more)
  • Favorite open source tool/app: RHQ (more below)
  • Favorite open source topic: Life

Open up to us.

I live with my wife and two kids in Stuttgart in the south western part of Germany. For those who don't know Germany well, it is the city of Mercedes and Porsche.

I work at Red Hat in the area of systems management and monitoring on the JBOSS project, RHQ-Project. As with many other open source projects, we use components from other open source projects. Often enough, when something does not work the way I expect it to, I just grab the source of those projects and go through it to better understand how it is supposed to work. And from time to time this also means that I create a patch and submit it back.

My involvement with open source started early. When I started programming and being interested in computers, I had the legendary Commodore 64 computer. Users were all equally clueless and everyone benefited a lot from the experience of friends and classmates of their local computer club. It was just natural to share experiences. At that time, we barely had anything Internet-like in Germany, so people also were very happy to get software in whatever form. This continued later with discussions on Usenet. As I explain in this article for Opensource.com, this quest just continued for me at the University.

Favorite open tools?

NetBSD operating system (I used to be a contributor), Raspberry Pi, the whole Gnu tools *ix command line tools. To some extend also the whole Android environment. Git and GitHub. And then there is c:geo as a Geocaching app on Android, which is pretty cool too.

I also benefit from people sharing their knowledge and experiences in blog posts and in online tutorials. Be it for quickly getting up to speed with a new piece of software or to avoid traps and pitfalls while using software.

What do you wish were more open?

Right now, my coffee maker. We bought a used one, and the previous owner broke the steam tube to create the milk foam. She bought a replacement part and gave it to us. Now I am struggling with disassembling the appliance to change the part. Unfortunately, there are no such manuals online, and the manufacturer told us there isn't one to buy. I am not totally unskilled in this area, but a hint here and there would certainly help a lot. It sort of feels like standing in front of Stallman's printer!

Another thing I wish were more open is our car. As the owner, I can't read the error recorder. I don't expect to write it, but at least just reading it with the help of a PC that would display the errors in human-readable text would be helpful for fixing issues that come up.

What do you see as the biggest challenges to openness?

This is interesting to contemplate. I guess there are two factors that sum up the challenges: fear and laziness.

Let me illustrate it.

I am working on the open source project RHQ and its associated downstream product Red Hat JBoss Operations Network. For RHQ we have the usual means of communication, an IRC channel and mailing lists. Also, because it is a product, we also deal with customer cases and data, so we also have internal communication counterparts. The fear of leaking customer data allows people by default to communicate on the internal channels only if they want to. And, laziness prevents them from filtering thier communications and doing the non-sensitive part on the public channels so that people can learn from the information being passed around there.

Why choose the open source way?

This is a "funny" question in the sense that the open source way feels so natural to me that it is not really a question of "why" anymore, which makes it harder to answer. But let me try anyway.

If you look at how children are raised then you'll see that they learn from copying you. They learn because parents tell them what they know already as knowledge distribution by inheritance through the genes is too slow. They learn from other children by playing with them and working together with them to achieve common solutions (building and enhancing a tree house for example). So basically, collaboration and sharing of results is a very natural thing.

Of course, there are always individuals that play on their own or who may want to take advantage of what the others have built; those are not the majority though. This process continues at school and at universities.

(Note: In Germany, public schools and universities are paid by the state; there are no admission fees. To me, that means that their knowledge is our knowledge.)

About the author

Jen Wike Huger - Jen is the managing editor for Opensource.com. On any given day, you'll find her running the website's publication schedule and editorial workflow (on kanban boards), as well as brainstorming the next big article. Learn more about her at Jen.io.