Author archive Karsten 'quaid' Wade

Twelve success metrics to improve open source-ness

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.


Secrets of an open source ecosystem revealed

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.


RPC smackdown – XMLRPC vs REST vs SOAP vs…

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.)


Rules and Drools Rundown

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 you get your software into Fedora?

“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:

  1. Follow the well established guidelines for packaging software for Fedora
  2. If you are an ISV of any size, connect with the ISV special interest group
  3. Once you have packages in Fedora, they are ready for EPEL. Request a branch

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)


Java in Fedora, first

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.


JBoss Application Server 5 CR1 available

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 .)


More how to get OpenJDK

A previous post, How to get OpenJDK 6 for Red Hat Enterprise Linux 5, covered how to install OpenJDK for Fedora Extra Packages for Enterprise Linux (EPEL) 5. Now these instructions are at an even easier URL to remember:

http://openjdk.java.net/install/#fedora

These instructions cover installing OpenJDK 6 for Fedora 9 and EPEL 5, as well as IcedTea 7 for Fedora 8. IcedTea 7 provides the OpenJDK 7 development branch with IcedTea components to make it build under Fedora using entirely open source components. The package name remains the same in the repository, despite the trademark agreement allowing the OpenJDK mark to be used by Fedora, because it is considered too disruptive to rename it now.


Fedora 9 lands carrying OpenJDK 6 and more for developers

Dev Fu focuses on the fresh and free OpenJDK 6 in Fedora 9 (Sulphur) because this is great news for developers. Especially developers who want to use the best software because it’s free and it doesn’t suck. However, there is much more of interest for developers than just OpenJDK:

  • Developers using Fedora as a workstation/laptop to develop on:
  • Developers targeting the environment for applications:
    • D-Bus improvements
    • More libvirt, the virtualization API
    • ext4, begin working now with the next iteration of this stable and standard file system
    • XULRunner now the common engine for Gecko using applications
    • Common dictionary used across applications fixes proliferation of dictionaries
    • freeIPA provides a common account system that can be adopted for an application
    • As Java based applications begin to get packages in to Fedora, many should land in Fedora 9. Hear that, JBoss.org fans?
    • … and OpenJDK 6!
  • Developers managing systems, such as testing and build:

For a good general overview of Fedora 9, read Fedora Project Leader Paul W. Frields article in Red Hat Magazine, “Fedora 9: Get yours and get involved“. The full feature list for Fedora 9 is also a good read.


The Journey of OpenJDK 6 into Fedora, EPEL, and freedom – podcast with Tom Fitzsimmons and Patrick Macdonald

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, and Karsten Wade making a Java sign Open

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.