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 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.)
As referenced in Ulrich Drepper Memoery Article Series, here is the sixth part in this series, now available for non-subscribers of LWN:
Memory part 6: More things programmers can do
From regular ol’ Red Hat Magazine is this article by Eugene Teo on how to prepare for, execute, and analyze a Linux kernel crash dump on Red Hat Enterprise Linux:
A quick overview of Linux kernel crash dump analysis
Believe me or not, but we thank the mysterious powers of the Universe for Ulrich Drepper every day. Don’t you? At least, you do if you use glibc. And you probably do. Uli has recently shown his deft style at touching both ends of the spectrum of programmers (newbies to oldsters) with a video series on Red Hat Magazine for those of us still grasping the details of a memory stack or needing a cluestick to remember to pay attention to the basics and the lessons learned.
We were seriously scooped recently when the venerated LWN began publishing a seven part series from Uli. Called What every programmer should know about memory, it is a thorough grounding in memory dynamics on modern hardware running Linux.
» Read more
This tip article is edited and republished from the original source.
by Andrew Oliver
In Java Performance Tuning on Linux Servers, Andrew Oliver covered some general and network performance tuning issues for JEE apps running on Linux. He now looks at issues for applications in the data layer. Lower level database issues, the higher level server application persistence model, and the interactions between the two are discussed. As before, it is assumed the application is “transactional” in nature. Most web applications, including client server and business applications fall in this space. (Messaging, analytical and ETL-type applications require different strategies, and different choices).
This article was edited and republished from the original source.
by Andrew C. Oliver
At JBoss, I was asked to help write some training materials for “performance tuning JBoss/Java on RHEL/Linux”. It wasn’t a very easy task because I knew the audience would primarily be composed of administrators who might not be interested in the whole system, compounded with the fact that most people mean performance and scalability when they say performance. What I would do to make one single client connect and perform its operations as quickly as possible on a single server is inherently very different from what I’d do for 10000 users connecting to a cluster. The type of performance tuning that I do for an application with no users and all messaging is very different from what I do for a standard web application-type system.
