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.
In his entry XMLRPC vs REST vs SOAP vs CIM vs RMI vs Message Bus vs … Lots of RPC Options, Michael DeHaan opens his experience with RPC protocols and pours it out on the page.
This is based on not only a few apps like Cobbler and Func, but also past work where I’ve touched almost all of these first hand — I always seem to get stuck working on the backend server components wherever I go. This is by design — I like it there.
Michael then goes down a list of RPC protocols, noting positives (+) and negatives (-) about each based on his time working with remote procedure calling. He is the founder and lead developer for Cobbler, a next generation Linux provisioning server, and a Func hacker, a “secure (and) scriptable remote control framework and API.”
(Edited to clarify that Michael is a hacker in the Func collective, not a presumptive leader.)
It’s been a good few weeks for stories and information about JBoss Rules and Drools, the open source project upstream of the JBoss subscription offering. Here is a quick summary of the recent stories. Post a comment if you know of any others we all should pay attention to.
“How do I get our software in to 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 candidate release (CR1) for JBoss Application Server 5 has been released. There is a lot of good background from Sacha Labourey and feature details from project lead Dimitris Andreadis. Now that version 5 of the new application server has been through alpha and beta stages, this candidate release is a great opportunity for developers to get knowledge and practice on the next gen app server.
(Tip of the hat for Ales Justin’s post about the CR1. Ales also posts new information about SpringDeployer and VFS .)
