This post really isn't about leadership in IT or higher education, but I wanted to share this very interesting article from the SD Times, from last year. When open source projects go commercial addresses the cultural issues many organizations face when they try to move into the open source software space. It's about the leadership triangle: strategic, political, cultural. And you need to get the culture right - even if you have the best strategy and all the political backing, your effort is doomed if you aren't able to fit the needs of the culture.
And that's the challenge for many companies that try their hand at open source software. The culture of business is to wring a profit from everything. Companies maintain their competitive edge by keeping certain things private, especially the source code to a project.
But the culture of open source software is the opposite: you can think of Free & Open Source Software (FOSS) culture as a meritocracy. The best idea usually wins out. You share your ideas through writing and sharing code. Other people may look at your source code, make an improvement (either to solve a problem they were having, or to add a missing feature) and re-share that improvement back to the community, usually by submitting the code change to the project's maintainer.
You may know that I've worked in open source software for a very long time. I first got my start around 1993, when I discovered a free version of the Unix operating system. This free Unix was called "Linux", and was built around free, open source tools known as "GNU". Everything was open, so you could look at the source code and make changes. It was a new way for me to look at software systems - especially having grown up with "closed" systems such as the original Apple ][ and the IBM-PC (although technically the original Apple computers were more open than the PC, in that you could find vast stores of technical documentation about the system - but no source code, so I still consider it "closed".)
I was so moved by using open source software, that I felt compelled to contribute back to the community. I made my first contribution around that time when I tried to implement the GNU editor (called "emacs") on a new Unix system that we used at my work, where I was a student intern. It didn't run correctly on the new Unix system, so I made a few changes that made it run better, and sent those edits back to the maintainer.
In 1994, Microsoft announced that they would stop supporting the old MS-DOS operating system, in favor of moving all their users to Windows. At the time, Windows 3.11 was a pretty awful operating system; very buggy, not very user friendly, and just plain ugly. I wasn't a fan of Microsoft's move, and preferred DOS to do all my schoolwork anyway. I realized that if "Linux" could implement a free, open source version of a complex operating system like Unix, surely I could do the same for a much simpler system like DOS. And so FreeDOS was born.
My involvement with FreeDOS has been an interesting journey. I've played all roles: from developer to maintainer to project coordinator. As the project coordinator, I have helped get people involved in FreeDOS - new contributors, and existing FreeDOS developers. Everyone has to work together if a project like FreeDOS was going to succeed. And that was my first foray into navigating open source culture.
Back to the SD Times article. It's an interesting read, and describes some things that work and do not work in open source software culture. Here's a great example from the article:
Jim Jagielski, chairman of the open-source Apache Software Foundation: "In corporate environments, the list of requirements and features isn't derived from the need of the masses. It's derived from 'What can we sell?' At some level, companies have to give up control. When [professional] open source understands the user community, it's incredibly successful," he continued. "But companies that try to wrest control, to fit the project into a pattern of traditional software development, are the ones who have problems."
Apache (a web server) has done well. But Oracle really stumbled when it took on stewardship of Java & MySQL during its merger with Sun Microsystems. "You would think they'd have a better understanding of what open source is and working with a community," Jagielski said. "With Java and Hudson, it seems obvious that the whole idea of open-source being a community-led effort is something they don't grasp very well."
Open source software and commercialization aren't necessarily polar opposites. It's possible for a business to embrace open source software in a very successful way. Red Hat Software is a great poster child for how to do open source business the right way; for Red Hat, it's all about the support. They contribute back to the community by hiring talented developers who provide fixes and make improvements to the very open source software they provide as a service to others. But at the same time, Red Hat works with the "upstream" project maintainers on the community level, integrating with the FOSS culture.