Java Goes Wild - Open Source Can Innovate!

There's a column in CIO magazine this month called Java Goes Wild. Eric Knorr, one of the editors at CIO, points out that open source has created a wide ranging of new and innovative solutions to the traditional problems of Java enterprise applications. (Think Spring, Struts, Ant, Jython, JRuby, Rhino, etc. etc.) So much so, in fact, that vendors such as Sun and BEA can no longer dictate the future of the Java language.

Hopefully this will help settle the on again, off again debates about whether open source can innovate. (See Age of Innocence) If open source can't innovate, then where did all these new Java technologies come from?

How to Get Support from Open Source Mailing Lists

It is possible to get outstanding support from open source communities if you know how to work with them. Of course, each open source community is different, so please follow its rules and etiquette.

How Open Source Community Support Works

Most open source communities are made up of volunteers. Its members are not paid to provide support. They're there to help each other and help the project. In recent years, as more corporations have started to contribute to open source, there are more contributors who are paid by their employers. In both cases, the contributors have a few things in common: They have a lot of pride in their project and want it to succeed, and they are also usually very busy.

As a result, it is very important on mailing lists to be respectful and to value others' time. This means that you must make it easy for them to help you by asking your questions the right way.

Asking Questions the Right Way

When I see a question on a list or forum, I usually scan and make a very quick decision on whether I would be able to help. If the question is unclear or there's not enough information, I'll usually pass--it's hard to track someone down with a mailing list. So, if you're asking a question, it is very important that you:

1. Get to the point quickly. In your subject and in the first paragraph, clearly describe what problem you are having. Don't use "Help me!" as your subject.
   
2. Furnish all the details. After describing the problem, describe what version you're running and what module or page you are having a problem with. If relevant, describe what platform or database you're using, and paste detailed error log messages. If you have screen shots, post them on issue trackers or upload them to your site and provide a link, but try not to clog up people's email with large attachments.
3. Try to do some research first. Some communities are more willing to help the inexperienced, but generally it's better if you've made somewhat of an effort to solve the problem first--for you and for others in the community.
   
4. Point out how your question might help others. Does it help answer common problems? Does it uncover a new bug?
5. Focus on solving the problem. Stay on topic; don't digress. Don't use your problem as an opportunity to complain.
   

Remember: If you make it hard to help you, fewer people will try.

Your Reputation

Longer term, how much support you receive from an open source community will depend on your reputation in it. This is no different than any other group, neighborhood, or community you might belong to. So, as you interact with others on mailing lists or forums, think about how they perceive you:

• Do you ask intelligent questions?
  
• Do you at least make an effort to figure things out?
  
• Are you pleasant to work with?
  
• Are you helping the project and other community members?

Most open source veterans agree: contributing back to a community, by helping others, writing documentation, or contributing code, will get you better support in turn.

General Etiquette

Finally, there seems to be a general etiquette or standard of behavior which applies to most open source communities:

• Keep your questions on the list. That way, the answers are available to other community members as well. In addition, many people feel that their emails are for work or personal use, so please respect that.
• Don't double post on multiple lists. If a community has multiple lists or forums, don't post to all of them at once. Try to figure out which one is appropriate.
  
• Be civil. Don't post questions like "Your !#@* software sucks" or use headlines like "HELP! HELP! HELP! HELP! HELP!" to get attention.
  
• Be patient. Remember others aren't paid to help you, and their help is a gift. If you can't afford to be patient, get professional support.
  

Why We Pay for Free Software

Why a professional open source software company like ours pays for open source software.

When I first found out about open source, paying was the last thing on my mind. Why whould I ever pay for something that's already free?

Five years later, we're working daily with over two dozen open source technologies, including all the major ones such as Linux, Apache, PostgreSQL, MySQL, Eclipse, and so on. We're part of the core group of developers for the Open For Business project and sponsors of Sequoia Open Source ERP. We've become savvier developers ourselves and fairly experienced with open source software and open source communities.

We're also paying for open source software.

Í'd like to tell you that it's only because we appreciate the hard work and effort of all the open source developers out there. But there's a simpler reason: it's also how we can derive the most value from our open source software. We've learned from personal experiences that getting complex software, both open source and commercial, to produce results is not always easy. With some open source software, we've spent days, sometimes weeks, searching online or asking questions on mailing lists.

Finally, it dawned on me: I can't run a business like this. It was different when open source was my hobby, and the open source software I worked with were small. Today, though, when our business and our clients' businesses depend on open source software, I simply can't afford to take my time figuring it out. We need immediate results.

I also realized that it was extremely inefficient to learn things from scratch each time. Open source software has gotten very sophisticated and feature rich in the last few years. With it, the amount of knowledge required to configure and implement them has increased exponentially as well. As a result, it's simple faster and cheaper to pay for the help of someone who knows it well than to try to figure it out on our own. (Hey, isn't that why we all went to school?)

Finally, as an open source developer, we've learned this:

The value of software is not the source code,
but knowing what to do with that source code.

So am I disappointed? In a way, yes. I was hoping that open source software was not just "free" as in "free speech," but also "free" as in "free lunch." Now I realize that the lunch is often free, but I might have to pay for wine and dessert.

In the process of working with open source, though, I've also realized that the real value of open source software is not "free" but "control." Having access to the source code gives us control over what we can do with the software today and well into the future. It gives us the flexbility to customize it as much as we need and frees us from vendor lock-in risk down the road.

Most of all, since we have the source code, we have complete control in deciding what services we pay for and when we pay for them. We're never at anyone else's mercy.

So that's why I'm happily using free software and paying for it as we need to.

Freeware vs Shareware vs Open Source

What are the differences between three models of "free" software, and why does it matter?

With all the excitement, many people are actually confusing open source software with two other models of "free" software--with potentially serious consequences. Here, we'll try to clear it up.

Freeware

The word "freeware" has been so overused, its meaning is no longer clear. Today it is often synonymous with "shareware," but for our purposes, I will define "freeware" as "software which can be downloaded, used, and copied without restrictions." (See this definition.)

Legally, the difference between freeware and open source is that you do not have access to the source code. Organizationally, this makes a big difference: There is no community and no development infrastructure around "freeware" as there is around open source software. Thus, while you can use freeware "as is," there is no real way to improve upon it or obtain support for it.

Thus, freeware is "free" as in those "Free Treadmill" classified advertisements.

Shareware

Shareware is a different concept. You can download and try shareware for free, but if you use it, you are supposed to pay for it. It is developed and released by someone who keeps full control of the intellectual property. The user does not have access to the source code and cannot modify it. There is also no collaboration or community around shareware.

In the end, the only difference between shareware and commercial software is that you can download and try shareware for free. Like commercial software, you are utlimately dependent on the developer of shareware for enhancements and support.

Thus, shareware is "free" as in "Free Sample" at restaurants or grocery stores.

Open Source

Open source means that the source code is available to all potential users, and they are free to use, modify, and re-distribute the source code. (For more details, see the Open Source Definition.) Legally, the "free" of open source refers exclusively to the source code, and it is possible to have support, services, documentation, and even binary versions which are not monetarily free. (Although some licenses, notably the GPL, requires that the source code always be freely available in such cases.)

In practice, open source usually means that the application is free to users as well as developers. Furthermore, most open source software have communities that support each other and collaborate on development. Therefore, unlike freeware, there are future enhancements, and, unlike shareware, users are not dependent on a single organization.

Open source advocates like to say that open source software is "free" as in "free speech," which is true. Since the user has the source code, it's also usually "free" as in "free lunch," even if sometimes you'd have to tip the waiter to get good service or pay for the wine.

In the Real World

The differences between the three models can be clearly seen in the kind of software that is available as freeware, shareware, or open source:

• Freeware is usually a very small program, released by a student or enthusiast.
  
• Shareware is usually a mid-sized utility or application, written by a professional developer or small software company. The developer or publisher does not have the resources to market it, so they release it as shareware with a "try-before-you-buy" business model.
• Open source spans the gamut, but the largest "free" software out there are all open source--Linux, FreeBSD, PostgreSQL, Apache. Before the advent of VCs in the "free software industry," collaborative development around a shared code base was the only way a large free application could be built.
  

Does It Matter?

At first sight, these differences may seem like legal subtleties. In reality, though, misunderstandings about the true nature of open source can be a serious hurdle to the adoption and development of open source software.

For example, corporate users often confuse "open source" with "freeware." Thus, when we talk to them about "open source," they immediately think of the little utilities that they can download for free. Nice to have, of course, but without support or enhancements, they are dead ends for enterprise users.

(In addition, users confusing "open source" with "freeware" probably contributes to the concerns about the security of open source software. "Freeware" and "shareware" often come bundled with adware or spyware, which is actually not possible with "open source" software: see Is Open Source Secure?)

On the other hand, investors often confuse "open source" with "shareware." Thus, they are investing in companies which engage in the "free sample" business model. Many of these companies try to enforce some form of de facto if not de jure protection of their source code. Their investors may be able to reap the rewards of cheaper distribution, but, in the end, they are still investing in a traditional software vendor, with all the same risks and rewards as before.

Thus, for enterprise users to adopt open source software, they must understand the advantages of open source software over freeware. Only then will they understand that open source software does not share the same security and support problems as freeware.

Similarly, for investors to become really comfortable funding "open source business models," they will have to appreciate the potential of open collaboration in producing better software--and how it improves their risk/return tradeoffs.

Community, Corporations, and Charity

Different ways for an open source community to provide for its needs and the strengths and weaknesses of each.

Every open source project has a society of users, and these socieites often have similar needs: new features, support, and documentation. Like any society, there are three ways to meet these needs:

1. Community - the members of the society, in this case users, get involved themselves. Each does what he can to contribute to the group. PostgreSQL and Debian seem to be organized this way.
   
2. Corporations - businesses are set up with investors, managers, and employees to satisfy the society's needs with the goal of making a profit. MySQL, Red Hat, and Sugar CRM are examples of this model.
3. Charity - someone provides for the society's needs without direct monetary gain, even though he may derive other benefits. OpenOffice from Sun and Mozilla during the early Netscape days are examples.

(The fourth option, "government," is thankfully absent from most open source communities.)

Community

Community effort offers the enticing advantages of empowerment, equality, and true free exchange of ideas. A veritable "liberty, equality, and fraternity" in the cyberworld.

Unfortunately, there are real limits to what community efforts can produce. First of all, volunteer efforts are dictated by what volunteers want to do. In many open source projects, this seems to be "write code" than "write documentation" or "help users." Second, community efforts depend on key organizers and ringleaders. Whole projects can be left floundering when they are not present. Finally, community efforts are harder as communities or projects get bigger, because each individual starts to feel that his contribution is simply too minute.

Corporation

Corporations can bring large resources to bear and achieve impressive results. They can also offer a greater level of reliability and predictability than unpaid volunteers. They can thus be very valuable in the ultimate success of an open source project.

On the downside, to maximize profit, corporations will usually have to assert some proprietary interests. Left unchecked, they could lead to the project becoming less and less free.

Charity

At first glance, charity would seem to be the best option. The community's needs are met without any strings attached.

Unfortunately, charitable resources are always limited, and participants have a limited role in the work of charities. (Hence the expression, "beggars can't be choosers.") Thus, charities can't be counted on to address most needs of a society at large or an open source community.

How Open Source Works

Typically, open source projects start out with charity--someone makes his work available. Then, as the project grows, a community grows up around it and begins to make more contributions. Finally, as it reaches a certain critical mass, corporations enter to provide services to the community as well.

With the renewed interest of venture investors, there's now been an inversion of this established pattern. A corporation is set up first with investor capital to create the initial work and build a community. It remains to be seen how well such corporations can live with the communities they inevitably create.

What's Right for Open Source

In a well-functioning open source society, all three components balance and complement each other. Community efforts keep corporations from asserting too much proprietary interests, while corporations bring their resources to provide services not possible with volunteers alone. It may well be that the community focuses on what it does best, such as developing software, while corporations pick up the task of support and documentation.

This has indeed been the Linux model--collaborative software development by a community, distribution and support by companies such as Red Hat and IBM. Commercial companies have popularized Linux far beyond the original developer circles, while open source communities such as Debian and CentOS keep their proprietary interests in check.

If the open source community becomes unbalanced, however, this "utopia" can easily degenerate into "distopia." If the community overly relies on charity of others, it will become a society of welfare recipients. Once those charitable resources are exhausted, the members will find themselves stranded and helpless. Conversely, if the corporations become the sole provider for a passive community, then the software will simply cease to be free.