Open sourcing code is more than sticking an OSI approved license on it and putting it up on a public repository. Discussing this is getting to be a bit of a theme at Dev Fu, as many of our experienced open source developers are watching companies and projects swing wildly trying to hit the ball.
In his post How Open Source Is Your Open Source?, Michael DeHaan covers twelve components that are needed for a company to successfully start and lead an open source project.
If you have an open source project, think about how to grow a community of users and a community of developers. The latter is pretty darn hard, but a pretty rewarding thing to achieve.
I could have written this more simply — open source code is great, open everything is better. Hopefully this is useful to some new software companies out there, as well as some developers. The main idea here is, think community, not code. It’s everything — and when you do that, THAT is when you actually reap the benefits of open source. Otherwise the only real benefit you are getting is freedom to debug/fork, which is only a very small part of the equation.
It has always been possible to solve the puzzle of Red Hat’s success in the software business. By piecing together Red Hat’s open source ecosystem methodology for their own understanding, many businesses have had an eye on Red Hat in how to organize their open source development practices. The idea of community and enterprise editions, for example, owes a lot to the split of Red Hat Linux into Red Hat Enterprise Linux and the Fedora Project.
Yet, there is a difference in how Red Hat started and grew compared to how some newer companies are running their open source-based business. Many offer closed source and proprietary add on components as part of their enterprise offering. Red Hat has always avoided this practice, striving to ship only 100% open source.
As the Fedora Project has grown, it has continued to pioneer open business practices that complement the open development methodology. The business model of taking the best from Fedora to support for seven years as Enterprise Linux lends itself to absorbing other practices from the Fedora community, ones outside of software. In every area, such as software packaging, documentation, translation, and marketing, Fedora’s open and highly visible work develops methodologies that affect the way Red Hat does business into the future.
It is not good enough to just act in this open, visible way. The open source model gains strength from community growth. The size of the community contributes to the quality of the software. This is in the best interests of everyone, including those who are paying actual staff to work actual hours on free software. Especially those people, as they get a force multiplier from efforts in the community, rather than going the road alone.
If it is a good idea to learn and grow business practices from community influence, wouldn’t the rest of the open source methodology concepts apply? The more pioneers of open business practices who are following an open source methodology, the stronger their work is.
One example of this is in the connection between EPEL, RHX, and ISVs. As the Fedora for ISVs page explains, there are a number of valuable gains to be had. By bringing your open source development work out more in to the community, you gain increased awareness, reduced maintenance burden, and a serious head start on the next version of Red Hat’s supported products.
This week, folks from RHX and Fedora’s Community Architecture teams are going to be at OSCON, talking with open source ISVs about getting their software in to Fedora. A strong point we are making is the chance to absorb and contribute to the open business practices, which are centered around the open source we hold in common, strengthed by all our contributions.
“How do I get our software into Fedora?”
This question has been a common one over the last year, brought to various parts of Fedora and Red Hat from software developers, community managers, and product teams working on open source software for various ISVs. Now that OpenJDK 6 is Java EESE 6 TCK certified, there is an even greater incentive for Java ISVs to get closer to the Fedora way of doing things. If your language has a free and open source implementation, it is probably in Fedora and might already be available in Extra Packages for Enterprise Linux (EPEL.) For example, take a look at how many Perl modules are available (I count 359 for el5, 236 for el4.)
Fedora anticipated this attention from ISVs when it created the EPEL project. In EPEL, package maintainers can branch any software and it’s dependencies for a special repository that provides Fedora packages for specific versions of Red Hat Enterprise Linux.
In one move, Fedora created a new and unique repository that has a compelling pathway for contributions. Fedora’s EPEL has a niche amongst repositories — be like Enterprise Linux. Focus on security updates and bug fixes to packages, not rebasing to the latest from the upstream project. This makes it possible for a contributor community to maintain nearly 1500 EPEL packages for Red Hat Enterprise Linux 4 and nearly 3000 EPEL packages for Enterprise Linux 5. Some of these packages may get branched for an Enterprise Linux update.
The answer to the how do I? question comes to this:
Along the way, you have an opportunity to grow a community around the open source software that matters the most to you. Getting software in to Fedora means a six to eighteen month jump on the Enterprise Linux beta. You can develop your software along with the operating system it runs on, and you may be able to help influence how other parts of Fedora are created.
(Edited to change “Java EE” to “Java SE”; OpenJDK 6 is Java SE compliant.)
(Edited to fix link to ISV SIG)
For those of us who slept through the month of June, the OpenJDK 6 stack in Fedora was certified as TCK compliant. Meaning it can carry the “100% Java(TM)” moniker. Rich Sharples has a nice write-up (with a second part answering the blogosphere):
In June, 2007 – Red Hat launched the IcedTea project with the goal of making OpenJDK usable without requiring any other software that is not free. That in turn would allow OpenJDK to be included in Fedora and other Linux distributions without restrictions. The IcedTea Project made use of previous work developed under the GNU Classpath Project which had been independently driving towards a free and open implementation of the Java class libraries.
This week [19 June 2008 - ed.] the IcedTea Project reached an important milestone – The latest OpenJDK binary included in Fedora 9 (x86 and x86_64) passes the rigorous Java Test Compatibility Kit (TCK). This means that it provides all the required Java APIs and behaves like any other Java SE 6 implementation – in keeping with the portability goal of the Java platform. As of writing, Fedora 9 is the only operating system to include a free and open Java SE 6 implementation that has passed the Java TCK. All of the code that makes this possible has been made available to the IcedTea project so everyone can benefit from the work.
At another point in his article, Rich mentions that we can expect to see this Java SE 6 in an update to Red Hat Enterprise Linux 5. The packages are already available from Fedora’s Extra Packages for Enterprise Linux, the source for the packages that Red Hat engineering is going to QA/test and build for the Enterprise Linux 5 update.
The first morning of JavaOne was a great serendipitous event. How often does something fall into place like this: I saw Barton George, who looks after Sun’s relationships with Linux communities, and we decided to cook up a podcast about OpenJDK 6 in Fedora 9. As we walked to the recording room, I commented that it would be great if we could get Tom Fitzsimmons, too. Not two beats later, we rounded a corner, and there stood Tom with Patrick Macdonald. Of course they were available and happy to record with us, and away we went.
Hear Barton (and a little bit of me) interview Tom and Patrick about the journey of OpenJDK and IcedTea: OGG and MP3
Patrick Macdonald, Tom Fitzsimmons (kneeling), and Karsten Wade. Photo: Barton George from this post The discussion covered the history of making a 100% free and open source runtime in Fedora from the initial Java open source code, which itself was 96% of a complete and self-building JDK. This remaining 4% was filled with components from GNU Classpath by the IcedTea team. The term “IcedTea” came from the package name used because, at that time, Fedora didn’t have a trademark license to use “OpenJDK”. Of the GNU Classpath code used, some if it ended up completing the circle to be included in OpenJDK. Based on relationships made at FOSDEM 2007, the team from Fedora/Red Hat were able to work with folks from Sun and other places to do work in the community in advance of resolving the remaining 4%, and do it in a way that could be more easily folded into OpenJDK. What is riveting about this story is the speed and quality of the outcome that is clearly due to the open source methodology used. By opening all the code that they could, Sun made it possible for others to fill the gaps Sun could not immediately fill. By working closely throughout that process, all of the open source code was used and tested in the community. Sun had time to choose the right license so the code could be merged. If Sun had waited until they could open all the code, we would have lost an entire year of development (at least.) Now that OpenJDK 6 is available in EPEL 5 for Red Hat Enterprise Linux 5, it is only a matter of time before it gets certified to appear in an update. This is being worked on by Keith Seitz and Mark Wielaard, who have “not many” test suites to complete to be ready to pass the TCK. Once that is done, the implementation can be called “Java compliant”, which is an important step to being ready for an Enterprise Linux 5.x update. Listen to the audio to get all the details, and check out Barton’s blog entry for his viewpoint.
This article is an explanation for why non-commercial use restrictions on free content are contrary to the goal of making it free in the first place. It brings the discussion more clearly into a realm that is understandable for creative people not familiar with what we’ve learned in the free software movements. Think of it like great science writing, able to explain a complicated concept to a layperson … yet still with lessons for the most experienced.
Matt Asay posted about an interview with JBoss middleware division GM Craig Muzilla, praising Craig for understanding why open source is not only a great software strategy but also a revolutionary business strategy. One of the comments to the article caught my attention:
“JBoss’ success has about 5% to do with the fact that it is open source, and 90% that it is good software, approximately.”
Thanks to the poster for his praise of JBoss software, but his comments exemplify a misunderstanding across various open communities. We can all agree that making a software project open source does not magically make the binaries better. The open source methodology combined with an open source license do get the advantage of several effects, which are key to the success of JBoss and other similar projects.
» Read more
