Page 2 of 2   « previous page

We set out to design Centric CRM first and foremost using only Open Source or freely available components. We chose the following:

• Platform - We wanted our application platform to be enterprise-class and totally cross-platform and portable. The only available platform that solved all our problems was J2EE. While the Java language itself is not Open Source (although I think it will be soon ), it's freely available and has a variety of free development tools and libraries. There are also compelling Open Source Java application servers such as Apache Tomcat and JBoss. We passed on scripting languages such as PHP and Python because, while they make great prototyping and rapid development platforms, they lack the enterprise security and scalability features we believed our enterprise customers require. They're also not well suited to building very large and complex systems. We didn't think the CIO of a typical Fortune 500 company would be receptive to a critical business application built on such a platform. And although Microsoft's .NET platform would have been a good candidate in terms of performance, scalability, and power, it certainly fell short in the Open Source category!
• Database - For our reference database, we wanted a system that we could distribute with Centric CRM that was very standards-compliant and provided very high performance and scalability. The only database in this class at the time was PostgreSQL. Another choice might have been MySQL, but seven years ago it didn't fully support the relevant SQL standards, and wasn't freely distributable.
• Operating System - There was really only one choice here: Linux. For our reference system, we chose Red Hat Linux.

Choosing Java as the development platform lets enterprise Open Source application developers be completely operating system-independent. If the application is designed with portability in mind, J2EE will let it run identically on Linux, BSD, Solaris, Windows, and just about any other operating system you or a CIO would be likely to specify. If the database interface uses only JDBC, standard SQL 92/99 queries, and no special or non-portable database capabilities, such as triggers and stored procedures, you have the beginnings of database portability. And if all the application's business logic is written in Java, the application will run identically and quite happily on PostgreSQL, Microsoft SQL Server, Firebird, Daffodil DB, DB2, and a host of other standards-compliant databases. (There's certainly a tradeoff in performance and convenience using this database architecture, but as long as adequate performance across a range of installation sizes is possible, I believe that the customer should be the final arbiter in the choice of database.)

Choosing Apache Tomcat as a reference application server lets one easily move to JBoss, WebLogic, or WebSphere when customers need the power and scalability provided by a full-blown J2EE application server environment. Taking advantage of the advanced features of enterprise middleware then becomes a matter of writing code that is "vanilla" enough to run on all of the available choices. Sometimes this involves a tricky design, but I've always found it possible. Furthermore, the development discipline such an approach enforces leads to the creation of very well structured code. (Download our source code as an example.)

The Emergence of an Enterprise Open Source Ecosystem
Centric CRM is by no means the only Open Source application developer that has thought through the issues involved in building true enterprise-class Open Source solutions. Indeed, one of the most exciting trends in the IT industry today is the emergence of a recognizable handful of serious enterprise Open Source products. Without the guiding hand of a single organization, there is now available a suite of complementary enterprise-class products that solve a wide range of corporate IT problems.

For example, in the content and document management space, you have Alfresco and Magnolia. For reporting and business intelligence you have Jaspersoft. For system and application monitoring, you have Hyperic HQ. For project management, there's Project.net. "It may take some getting used to, but Open Source is the way of the future for enterprise software," says Peter Winston, CEO of Project.net. "With the product source code, customers have the ability to customize applications to their own specifications in much less time and at a much lower cost of financial and human resources."

The emergence of this suite of enterprise-class applications is also creating tremendous opportunities for VARs and systems integrators with Open Source expertise. "We are now able to offer our corporate customers cross-departmental Open Source business functionality," says Ron Bongo, CEO of CorraTech, a large East Coast Open Source integrator. "By delivering solutions using Open Source code within a Service Oriented Architecture (SOA), we can provide deep integration that's maintainable."

An Enterprise Open Source License
Despite the lack of a guiding hand, all of these vendors have made substantially similar choices in the architecture they've chosen. In particular, they have all chosen J2EE as a development platform. They've also made substantially the same choices about how they license their products. Consensus is building around the key elements an enterprise Open Source license must embrace.

In particular, the following elements are important to an effective enterprise license. First, the source code must be truly open. Virtually all of the vendors mentioned above have turned away from the dual license in which a stripped-down community version is offered under an open license, while a separate proprietary license governs the use of the complete version of the product. Instead, most of these vendors - Centric CRM included - make their full product source code available for download under a single open license.

Second, the license must discourage "forking" the code. As long as large enterprises have to worry about multiple variants of a product emerging, they won't embrace Open Source solutions for mission-critical applications. Instead they need a unitary code base backed by a real vendor offering professional service and support. An enterprise Open Source license creates this condition by restricting redistribution of the source code. So while the full source code is truly open (i.e., freely available to download and inspect), it can't be resold (presumably with modifications) without the vendor's permission. Finally, any modifications that a customer makes to the application for its own internal use must belong to them. Customers who undertake meaningful development to create significant competitive advantage for themselves can't be forced to submit their enhancements back to the core product involuntarily. That said we've found that in practice all of our customers want their enhancements merged into the core code so that they're relieved of the burden of maintaining those enhancements in the future.

True Enterprise-Class Open Source
After seven years of dedicated design and development, we now have exactly the same code, governed by a single license, running in a five-person shop under Linux, Tomcat, and PostgreSQL and in a Fortune 500 company running HP-UX, DB2, and WebSphere in an installation that will soon have thousands of simultaneous users in a fully clustered and replicated infrastructure. (There are, of course, many other customers between these two extremes.) Our goal all along has been that the customer should have ultimate control of his application and the infrastructure it runs on. I am proud to say that we've achieved that goal.

In summary, by choosing the correct operating environment, using sound and sensible design, and keeping one's eye on the goal, it's possible to craft an enterprise Open Source application that's accessible to customers and the community, is portable across operating systems, databases, and application servers, and runs on a 100% Open Source stack. I've provided a high-level view of how a single identical code base, governed by a single Open Source license, can be as appealing and accessible to a shop running it on an old desktop machine with 256MB of RAM as to a large data center using all the power of an enterprise-class infrastructure and run by a battle-hardened CIO.

True enterprise Open Source applications have arrived.

Page 2 of 2   « previous page