Open source in a new light

Open source software is no longer just for alpha-geeks

So you've got to cut costs, but you're not a manager. You're a software developer, or a power user, or just someone who needs to keep the bottom line healthy enough to support your salary. These are ideal situations for introducing open source software solutions into your environment. That might sound like you'll spend the next three weeks learning to program or write makefiles, but it's just not so. Read on and see how open source is a flexible, usable approach to efficiency in your work environment.


Brett McLaughlin, Author and Editor, O'Reilly & Associates

Photo of Brett McLaughlin Brett McLaughlin is one of the leading authorities today on enterprise programming. He has designed, architected, and implemented enterprise solutions at Nextel Communications and Allegiance Telecom, Inc., and helped develop the Lutris Enhydra open source J2EE application server. He has written books on XML, Java, data binding, and enterprise applications, and is the author of over 50 articles on enterprise programming. Additionally, Brett is a committing member of every open source J2EE application server available today: JBoss, Enhydra, and OpenEJB. He is also the co-founder of the JDOM API for Java and XML, the Apache Turbine project, and is involved in numerous other open source projects. He currently writes and edits for O'Reilly & Associates, the world's leading technical publisher. Contact Brett at

20 April 2010

Also available in Russian Japanese Portuguese

Open source in 2010

Before you tune out, this isn't some grand state of the open source union. If anything, this is an attempt to dispel the myths brought on by a wealth of exactly that sort of state-of-the-union approach. If there's anything you need to begin thinking, it's this: Open source is no longer an all-or-nothing choice. In other words, nothing in this article is going to insist that you dump Windows®, install GNU Linux®, or curse Adobe or burn Apple in effigy.

What this article does attempt, is much humbler: to convince you that open source software is a solution for some subset of problems and that some of your problems most likely exist within that subset. So whether you have browser issues with Internet Explorer®, are looking for a nice code Integrated Development Environment (IDE), are tired of paying for PhotoShop, or just want a closer-to-real-time support system, open source might be just right as part of your software stack.

A hybrid approach is almost always best

Let's assume you're not into open source for purely philosophical reasons. That's not to say you may not appreciate the open source approach; it's simply stating that you have pragmatic concerns for looking at alternative solutions to software issues you're facing. Given that, you're probably not a candidate to go "all open source." So you're going to have some software — even the majority of your software — that is "closed source." That means the software is commercial or just doesn't give you access to the source code. That's fine. There's nothing that suggests it's bad form to mix open source and non-open source software.

In fact, a hybrid approach to open source is your best option. In this approach, you find one or two problem points in your current environment. For example, suppose you're on Windows and Internet Explorer drives you batty. If you switch to Firefox, that's a hybrid approach to open source. (Yes, if you didn't realize, Firefox is built squarely upon open source software.) You're mixing commercial software, like Windows, with open source software, like Firefox. You're getting the best of both worlds without having to live entirely in one or the other.

The balance between your open source and non-open source software is completely up to you. You may never use anything more than Firefox. That's great. On the other hand, you may lean toward the Ernie Ball approach advocated by Sterling Ball (see the link to the Ernie Ball story on CNET referenced in Resources); they're almost entirely using open source software. In either case, or in the places that exist between, you're making choices based on what you need, and that's a good thing.

Open source doesn't mean developers only

As a developer who's worked on open source projects for nearly 10 years, I'm well aware that a lot of open source communities have traditionally been closed and even snobbish. Ask a question on a user list that someone else asked eight months ago, and you'll get a snide, "Read the archives, newbie!" Submit a request for a feature, you could be blasted with a, "Quit complaining and fix it yourself. It's open source." These are horribly arrogant, developer-centric approaches to open source.

Thankfully, most projects with this sort of ethos have either disappeared or dramatically changed. Developers with even a bit of decency have pushed back or even left projects over this sort of behavior. Now, in 2010, most open source projects not only have strong user lists that are patrolled by helpful developers but in fact integrate Facebook, Twitter, and LinkedIn as supplemental communication channels. Bug-tracking systems are common fare for projects, so you can submit a feature request or bug without fear of getting attacked. In fact, the best projects welcome these reports, as they improve the project.

As an example, Xalan-J, an XML processor and transformer, has an extensive page detailing how to handle problems, shown in Figure 1.

Figure 1. Xalan-J provides a clearly written page detailing how to report problems
Screenshot shows how you can submit bugs easily through a Web page

Not only are you given instructions but there's a user list mentioned to help. While this page does advocate you trying to fix a bug, it's worth noting that Xerces-J is by nature a pretty low-level code project. Still, there is information on how to submit a bug using JIRA, a nice, full-featured bug-reporting API (see Figure 2). In other words, you're not dealing with weird text-only UIs and convoluted instructions. Bug reporting and feature requests are documented, easily accessible lanes to flow through as a user.

Figure 2. JIRA offers robust bug reporting, and it's completely open and accessible to users
Screenshot showing how JIRA reports on bugs, both open and fixed

Community is a good thing

Ultimately, the sort of interactions described here rise to what can fairly be called community. While it's possible to simply fire off a request for help or file a bug report and then dive back off user lists, that's not the norm. Most users that subscribe to a software project's mailing list end up hanging around. They find other users that are either working in the same problem domains, or facing similar problems in another domain.

While it sounds simple, and even overly idealistic, community forms in these e-mail lists and support sites. You'll find people you never would have met that can offer advice, or that you can offer advice to, in the context of your software issues. Returning again the earlier-referenced article on Ernie Ball: Sterling Ball's experience with open source did more than improve his business: It caused him to feel a desire to let others in similar situations know how they dealt with a very real problem, and overcame that problem. As a result, many other companies are trying variations of Sterling's and Ernie Ball's solution.

Open source software seems to breed these sorts of communal initiatives. Whether it's the nature of having open e-mail lists or that the software evolves quickly in the open, interaction seems to foster. Certainly, nobody seems to seriously oppose interaction for its own sake, even commercial companies. But with open source software, that interaction seems to foster further interaction, and user-to-user interaction, especially well. That is a not-so-trivial benefit of open source.

Open source software is open

I try to avoid clever titling — of books, sections in an article, you name it — but here, the thing just needs to be said: the "open" in open source isn't redundant or unimportant. Yes, let's assume you have managers and corporate interests; the first section of this article should have spoken to them in detail.

But by virtue of you hanging out on IBM® developerWorks, I'm going to make another assumption: You've at least got a developer mentality. Maybe you don't get to code as much as you'd like, but you're still thinking like a developer. That's a good thing. That's also, honestly, where open source shines even more brightly. Once you've gotten beyond hybrid approaches and community, your concerns become more technical; and open source meets most of these concerns extremely well.

Self-documentation is often belated, but useful

First, the bad news: Developers are notoriously bad at documenting their code. That means that if you're going to dig into Xalan-J or Firefox or your favorite project on, you're not always going to find really good documentation (links to all of these projects are in the Resources section). It's not unheard of to see a method named initParser() labeled with something extremely unhelpful like "initialize the parser." That's hardly helpful.

However, the more mature a project and its code base, the better the documentation tends to be. Take the JDOM project, which has been around for a number of years (see Resources). JDOM is an open source API for parsing that is more user-friendly than SAX or DOM. In fact, lots of folks — from NASA and even Sun Microsystems (now Oracle) — are using JDOM. Part of that usage comes from its well-documented API. For instance, Listing 1 shows the code for just one method in the Element interface.

Listing 1. Sample of JDOM internal documentation
/**  * This protected constructor is provided in order to support an Element  
       * subclass that wants full control over variable initialization. It  
       * intentionally leaves all instance variables null, allowing a lightweight  
       * subclass implementation. The subclass is responsible for ensuring all the  
       * get and set methods on Element behave as documented.  
       * When implementing an Element subclass which doesn't require full control  
       * over variable initialization, be aware that simply calling super() (or  
       * letting the compiler add the implicit super() call) will not initialize  
       * the instance variables which will cause many of the methods to throw a  
       * NullPointerException. Therefore, the constructor for these subclasses  
       * should call one of the public constructors so variable initialization is
       * handled automatically.  

       protected Element() { }

As a developer, this is tremendously helpful. There's no confusion, and using this class just became a lot easier. Of course, most languages — including the Java™ language — allow this sort of code-level documentation to be turned into something even more usable. Figure 3 shows the JavaDoc for the Element interface, generated directly from the code documentation above.

Figure 3. JavaDoc is a visual representation of code-level documentation
This documentation is auto-generated from comments in code

Large communities are large support staffs

Build out this idea of code-level documentation. First, a developer writes some documentation. Then, others on the project interact with that code and either refine or have the original developer refine their documentation. So the documentation improves.

Then, users start to interact with the code. Some of these users are going to find problems, report them, and even help fix them. Documentation grows.

As the user base grows, something else happens: Several of those users will be type-A, ultra-detail-oriented types (and I can say that because I'm one of these people). These people will dig into the code base and improve the documentation. They can't help it; it's in their nature. So even though some of these users will never change the code's functionality, they're improving its documentation.

All throughout this process, the user community is becoming the support community. Answers are fielded by a growing group of stakeholders — many of which aren't paid or even affiliated with the original source code base. For instance, check out the Eclipse project's forum for newbies (see Resources). This is an open source development environment. Scroll through the various posts; it's shocking how many are answered — and answered thoroughly — by folks without an e-mail. These aren't IBM's folks being sneaky. Instead, you're seeing how an open source community quickly becomes a support community. This isn't commercial software, is it?

Can you really mail Microsoft directly?

OK, so this is a little bit of a jab. The issue is real, though: The bigger the company, the harder it becomes to get quality support. When's the last time you felt like you might get a personal e-mail dealing with your problems with Excel® or Mac OS X? While it occasionally happens — and appears to often be as much about PR as real support — it's not the norm. And while you can certainly buy support contracts, it's really a roll of the dice as to who answers the phone when you call.

Now, to be clear: I, as I'm sure you, have had great support experiences. I've had folks ignore that I'm out of my registration period and help; I've gotten great and carefully worded explanations in e-mail minutes after hanging up; I've been called just to follow up. There's nothing at all that says commercial companies can't have great support.

Further, many open source software projects have companies that have grown up to provide support for those projects. Some use these companies, others don't. So support can be just as "commercial" in an open source environment as in a closed-source one. Stereotypes rarely help, and make you and those who might share your position look foolish more often than not.

However, consider what's been laid out here: Support is no longer the primary domain of a select few paid individuals. Code documentation provides support. Your reading that documentation makes you more knowledgeable, and in many cases, self-supporting. The group of users form a larger support community. Ultimately, I would rather rely on someone who has just spent all night chasing a bug I now have to give me great advice over someone paid to read answers out of a FAQ — no matter how great and detailed that FAQ.

Open source software is iterative

Iteration is a term that's tossed around a lot. It shows up particularly in software development circles. In open source software, iteration loosely refers to the software's tendency to release often. In fact, that's a core idea of open source software: release early, release often. So you could easily have 15 or 20 releases between major releases (2.0, 2.1, 2.1.1, 2.1.2, 2.2, etc., then finally 3.0).

There's nothing here to suggest that commercial software doesn't also iterate. However, those iterations are often hidden from the typical and common user base. Even software like Windows and Mac OS X — though updated frequently — downplay those updates with unobtrusive slide-ins and slide-outs at the bottom of the screen, or in minimized windows. Why? Because for most commercial software, revision is seen as correcting mistakes. The more revisions, the more mistakes have to be corrected.

With open source software, the opposite is true. The code is in the open, so if there are mistakes, everyone knows about it. Just subscribe to a user list for JDOM or Xalan-J or Eclipse or Firefox. The bugs aren't secret. Log on to JIRA for any project you like. The result? Frequent releases and revisions to fix those mistakes. What's to hide, right? And with those frequent releases, you — the user — can get some nice upside.

You control the feature requests

When software releases often, and there are no real bugs that are "hidden," then you've got an ever-evolving code base. As a corollary, then, feature upgrades are easy. If you're already releasing once a month, or even more, what's to keep software from adding features, not just fixing bugs?

Now, think this through. The user community is the support community, finding and fixing bugs. The developers are engaged with their audience because they are also the audience. So who is controlling feature requests? A manager somewhere? A board of shareholders? A project manager? Well, no (although all may be involved at some stage or another). You're in control. You're the audience. You're the shareholder, in many ways.

Ultimately, frequent release means frequent improvement. Bug fixes are an improvement, but so are upgrades in functionality. And since the development's in the open, you're a large influencer. On JDOM (on which I was a co-creator and long-time activist), most of our major software changes were in response to user requests. The move to a version that had more interface-driven support was pioneered by a user who had no "official" relation to the project. He just got involved. Eclipse is largely driven by clever programmers who come up with new users for the code base.

Open source software tailors itself to you (sort of)

Ultimately, long-time users of open source software are a force that tailors that software to their needs. You can be silent, never join a mailing list, and just let quality be your sole decider. That's largely what drove Ernie Ball. On the other hand, your engagement means you gain control of your software. The feature requests you have get communicated, and you're even empowered to add your own functionality.

At the same time, you're tailoring yourself to the software. That's not a bad thing. Frequent use, and the sort of understanding of a code base that open source provides, allows you to tailor the way you work to what your software does best. You'll find that as your knowledge of your software's inner working grows — a natural effect of you engaging on user lists and even helping with the code — you make decisions that optimize that software's use. You know the hooks, you know where it performs well, and you know where there are problems. And, ultimately, you'll take advantage of that knowledge and perform better.


Most articles you'll read about open source these days are religious rants, or at best, they're practically focused, but there's still an air of fervor underneath the prose. For many years, open source advocates have used philosophical arguments to bolster their case. Advocates seem to desire converts more than users. That's a big turn-off — not just to non-developers but to many programmers who don't have time to plant an open source flag next to their cube.

What this sort of near-propaganda obscures, though, is the real benefits of open source software. Used judiciously (that's a less-offensive way to say, "Don't use open source everywhere in most cases!"), open source software can reduce costs and, in some cases, actually improve functionality. As mentioned, Firefox is the most obvious example to most casual users: few people install Firefox because they have an open source agenda. It's just a really useful browser, with more plug-ins than all the other browsers combined. Why? Because the software is supported by an active, vibrant community.

Perhaps the best argument for your consideration of open source software in a hybrid environment remains IBM itself. (Yes, again, this is an article published on an IBM site. Still, the statement holds.) IBM seems to be managing to make ends meet with its commercial offerings and still has a healthy list of open source software floating around, from donations to Apache to Eclipse and the rest. This approach — using open source when it makes sense— is the approach commended to you.

Maybe you don't like Gimp, and PhotoShop is your best bet. Maybe synchronized bookmarks through Safari across your desktop and iPhone really is the best solution. That's great. Just don't throw out every other piece of open source software in a short-sighted flurry of indignation. (That sentence sounds just as overly dramatic as is the action it describes.) If you need quick upgrade cycles and late-breaking features, look at open source alternatives. If you need support without dropping tens of thousands of bucks a year, check out what open source has to offer in a particular area. And whatever you do, be informed. Make good choices based on good information. We'll all be happier. And let us know what particular open source offerings you choose — and refuse — and why. See you online.



Get products and technologies

  • Eclipse is one of the better IDEs around, and has an extensible plug-in architecture. Best of all, it's completely open source.
  • Xalan-J is an open source XML processor, built on and around all open source parsers and tools.
  • JDOM is an open source parser API, built out of a frustration with the existing APIs. This is open source at its most raw: fix something because it's broken.
  • Check out Mozilla Firefox, a best-of-breed Web browser, and the best starting point for checking out reliable open-source software.
  • Innovate your next open source development project with IBM trial software, available for download or on DVD.
  • Download IBM product evaluation versions or explore the online trials in the IBM SOA Sandbox and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Open source on developerWorks

Zone=Open source, Linux
ArticleTitle=Open source in a new light