The culture and environment in an open source community makes a big difference, and the same is true for company cultures. A lot has been written about this issue elsewhere, and you can find some great examples of how this happens on the Geek Feminism Wiki FLOSS webpage. In open source communities and at Red Hat, there's a strong desire for meritocracy—letting the best ideas win, regardless of their source. But diversity is a crucial component of meritocracy. How can we be confident that we have access to the very best ideas, if we are missing the perspectives of distinct groups of the population? Including people from many different backgrounds and cultures leads to greater diversity of thought and ideas. Research indicates that diverse groups are more innovative and make better decisions. For the technology industry and for open source communities, the lack of women is particularly concerning, because women represent half of the global population and workforce. In the past few years, I've also become increasingly interested in the role of unconscious bias and how it impacts the job application and interview process. Our human tendency is to instinctively prefer and value people who send unconscious signals that they're one of us—that they share our beliefs, background, or other social interests. It's easy for us to overlook the contributions of someone who comes from a different gender or culture. We don't even realize that we're doing it, and we construct explanations for our preferences that seem rational. Unconscious bias a fascinating topic, and plenty has been written about it, so I encourage everyone to seek out that information and put it to good use. It's something that Red Hat now educates our associates on, as part of our job interviewer training. I think it's equally relevant when it comes to cultural norms within open source communities.
Open source projects live and die by their communities. Cultivating that core group of developers, administrators, users and other contributors who work together to improve the code base is no easy task, even for experienced community managers. There are some tried-and-true methods to follow, however, pioneered by some of the best open source communities around.
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.
I was introduced to open source nearly 15 years ago by a friend when I asked him what that foot thing was bouncing around on his screen saver. He then explained what GNOME was and what open source software was. I was hooked immediately; the philosophy and methodology made perfect sense to me. It took awhile for it to become the focus of my career, but it's been an incredibly rewarding path.
Sometimes a gift just falls in your lap. This month, it came in the form of an e-mail out of the blue from Jared Nielsen, one of two brothers (the other is J.R. Nielsen) who created The Hello World Program, "an educational web series making computer science fun and accessible to all". If it had been just that, I might not have been interested.
But when I looked at it, I saw it was hugely about Linux. And the human story was interesting too. Wrote Jared, "Working in rural Utah with minimal resources, we combine technology and craft to make educational yet entertaining videos and tutorials. Learn to code with our cute and clever puppets." So I said I'd like to interview them, and here's how it went.
I’ve been using Linux since around 2003. I think my first distribution was Slackware, followed by Debian, but it wasn’t very long before I discovered SUSE and since then I’ve been hooked. I started contributing with the great ‘opening up’ of the distribution that came with the launch of the openSUSE Project in 2005. In terms of ‘upstream contributions’, I’ve contributed to GNOME, ownCloud, Spacewalk, Cobbler, and a few other projects over the years, but normally through my involvement with openSUSE. I guess you could say I’m a little ‘Geeko-centric’ that way.
Dan Allen: I can understand the programmer's dilemma in having to write documentation. It can be a long and painful process. Documentation in open source is often a missing link. There are four major pillars of developing open source software. Each one has it own elements of problem-solving associated with it. These are design, code writing, testing and documentation.