Success Tips from SourceForge’s Top Open Source Admins

Open Source isn’t all about plotting the demise of Microsoft. In fact, it’s just the opposite. OETfound Successful projects work with the giants rather than cutting them off at the knees.

That’s only one of a number of surprising tips OET found when we conducted a series of interviews with the admins for the top Open Source projects on SourceForge to see what lessons these experts can offer to budding Open Source projects. Take a look at some other suggestions to help your project become the next hit.

Persistency Over Proprietary Solutions
Persistency challenged the Java Business Process Management (jBpm) project. J2EE’s built-in object relational mapper wasn’t powerful enough.

“All commercial (and the Open Source) application servers overcome this problem by providing proprietary extensions,” administrator Tom Baeyens told OET. Using server specific extensions made it harder to run jBpm unmodified on different servers. To solve this, the jBpm project made an unusual choice: Rather than extending their code to massage the peculiarities in each database, they chose a non-standard mapper called Hibernate and distributed it as a component, neatly excising the problem. Like other Open Source developers, Baeyens sings the praises of letting go.

“We couldn’t have done this if we didn’t release early and release often,” Baeyens said. “Releasing early generates feedback at a stage where it’s still relatively easy to apply changes. If it weren’t for the feedback of our early adopters, we would have discovered the problem much later, making it harder to change our persistency mechanism.”

Project name: java Business process management (jBpm)
Project description: “jBpm is a business process engine. It separates the business process definitions from the engine that manages the execution. The process definitions are based on UML activity diagrams. jBpm serves as an excellent integration platform because it’s packaged as a J2EE-application. This means that it can run on any J2EE application server like JBoss, BEA WebLogic and IBM WebSphere.”
Project URL:
Operating systems: jBpm is platform independent.

TIMTOW — There Is More than One Way 
As the Perl motto goes, “There is more than one way…” The Quartz Enterprise Job Scheduler had problems with portability and integration when server software makers and database developers strayed from established standards.

Quartz runs on any one of 15-plus databases. Rather than using a different mapper, Quartz coded “bridges,” extending its base implementation. Early adopters were integral in identifying nuances in the databases. Most important, however, James House, administrator of the Quartz project, advises some defensive foresight:

“Plan for differences and incompatibilities in the products of various vendors to begin with,” he told OET. “Although this has become standard practice for most software engineers, the value of doing so cannot be understated, as refactoring your application’s code to support the bridge pattern later can often be a significant-sized task.”

House has even more unusual advice. “Depending on the nature of your product, it may be wise to stay away from using leading-edge features, or features upon which the various vendors have not yet fully standardized,” he says. “This may mean implementing some functionality yourself, rather than using what’s ‘already available,’ and although this is usually unfavorable, in some cases it may be exactly what you should do.”

Project name: Quartz Enterprise Job Scheduler
Project description: “Quartz is an enterprise-class job scheduler for
integration with stand-alone Java applications and full-blown J2EE applications. It features very complex scheduling capabilities, for
executing jobs of literally any complexity. ”
Operating systems: Any OS with a Java Virtual Machine. (Windows, Mac OS, Unix, Linux, AS 400, etc.)

When a Request Is a “Real” Request
For Compiere, a CRM and ERP solution for small to medium-sized enterprises, meeting a plethora of demands was too big a task. For example, many users have requested Compiere to make database independence a priority.

When faced with a complex task, the Compiere team has an interesting way of gauging the true amount of interest: They ask for donations to support the development. “A commercial
application with Compiere’s functionality is $30-60,000 in license alone,” project administrator Jorg Janke told OET. “So far, we received well below $3000 — a clear indication that (requests for database independence) is mainly talk and no real demand.”

Janke shared other lessons he’s learned from taking requests at face value. “Business applications have too many options and alternatives. We broadened the scope due to perceived requirements, not concrete customer requirements. (Now) Compiere has a very rigorous scope policy… the main challenge is to stick to it and deliver.”

As a result of trying to fulfill all the feature requests, the Compiere team accepted uncompleted, untested contributions — which destabilized the application. Their cure? Don’t coach beginners. “A Compiere committer must have at least five years of development experience in complex application database environments, be very fluent in Java and SQL, and know the subject domain: accounting, costing, etc.,” Janke said. “We now have code reviews and formal sign-off. This is not typical Open Source style, but (is) the standard in any good application development company.”

Project name: Compiere
Project description: ERP and CRM for small to medium-sized enterprises.
Project URL:
Operating systems: Compiere is platform-independent.

It Takes a Network to Gain Respect
Sandeep Dixit of OhioEdge CRM, an Open Source customer relationship management product, has a unique view of commercial versus Open Source software.

“An Open Source product takes a lot more than writing good code,” said Dixit. “Work in partnership with other Open Source project administrators. Form collaborations. Give due credit to other Open Source libraries you use. That’s the only way we can offer substantial value to the business community,” he explained. “Only together we will become a successful group.” Dixit’s best advice for other Open Source project admins can be summarized in three words: Network, Network and Network.

Dixit comes to these conclusions after getting his degree from the “Open Source School of Hard Knocks.” Dixit told OET that he came to a realization after examining the differences between commercial and Open Source: It’s a company’s name recognition and financial backing that give commercial software a veneer of respectability, he said, but in the end, the code is mostly the same code as that in Open Source products.

He looks to the Java world to prove his point. “In Java/J2EE, commercial software is 85-90 percent Open Source code,” Dixit told OET. “If commercial software is quality, then Open Source software must be quality software, too. Our challenge is to send this message to potential buyers.” So, to gain respect in the market place, OhioEdge sought J2EE verification by Sun Microsystems. OhioEdge is one of only six projects to be certified. Sun has been very supportive, but it was the realization that OhioEdge needed to have a strong network — not simply strong code — that made the difference.

Project name: OhioEdge CRM
Project description: “OhioEdge CRM is a web-based, enterprise customer relationship management portal application built for $2-500M organizations seeking centralized enterprise-wide coordination of sales generation (contact management) and sales fulfillment (workflow management) activities.”
Project demo URL:
Operating systems: OS Independent. Enterprise Java (J2EE) 1.3-compliant application server (JBoss, WebSphere, WebLogic, Oracle9I, SunONE, etc.)

Open Source Needs Marketing Savvy
As tough as it may be for many Open Source developers to hear, Brian Chan, admin for the Liferay Enterprise Portal, said Open Source projects need sizzle and good word-of-mouth. That means marketing.

Without marketing resources, Chan told OET, Liferay Enterprise Portal found it hard to communicate its value in the marketplace. “Customers aren’t willing to spend time and money on an Open Source project unless they believe your product has a momentum and can thrive in the future,” Chan said. “The key is to make sure that your Open Source project gets lots of attention so it can gain momentum.

Chan admits, “Our mistake was that we focused solely on our product and making it great. We neglected marketing, thinking it was of no use, but we’ve learned our lesson. A good product with bad marketing means no one will use it.” For devs who might be a bit reluctant to spend on marketing rather than code, Chan has another epiphany. “A great product with great marketing will become an Open Source standard.”

To get marketing to critical mass, Liferay has two or three project members whose only job is to evangelize products at the grassroots level, attempting to mimic the success of and As an overall strategy, Chan sums up what all administrators seem to have in common: “We’re constantly learning from older and more mature Open Source projects; observing why they succeed and why they fail, mimicking the good and avoiding their pitfalls.”

Project name: Liferay Enterprise Portal
Project description: An enterprise-level web portal.
Project download URL:
Operating systems: Mac OS X, Windows, Linux, FreeBSD, UNIX