Another Internet Matt

Evaluating Open Source Options

The great thing about open source is that there are usually a ton of open source projects to help you solve a problem. The bad thing about open source is that there are usually a ton of open source projects to help you solve a problem. Part of a good open source developer is the mentality to test and evaluate different projects and then choose the best option for your current problem.

I do a lot of development in java. For every type of framework or library you would need, there are a ton of java options to go through. In this post I will outline my thought process on how I evaluate which java product to use in development.

The first thing I do is find what options are available. This is just a bunch of googling and reading message boards to see what projects names are most popular. I also use Open Source Software in Java. This is a great website that categorizes and summarizes the major java open source projects. Once I am familiar with the major names, I go to the project website and start to work through the introductory documentation and “Hello World” examples. At this stage, I physically don’t write the “Hello World” code, instead I just read over the documentation and get a grasp of things work. I know many people will start doing prototypes and such to evaluate options, but I just prefer to do more reading.

So now that I know my options and roughly how they work, how do I choose? There is no set formula, but here are some of the criteria that I use:

Documentation
This goes along with my research phase. Projects with good documentation are much easier to work with. If the project leaders have not written a lot of documentation, then they will most likely not be very forthcoming with support requests. Sometimes programmers put the documentation inside the code itself and solely rely on things like javadocs. This is nice that they wrote something, but digging through javadocs can be a pain because it is often hard to piece together how the classes interact.

Community Activity
The project community is another great place to get support. I look for projects that have active communities with participants outside the sponsoring company. If the community is just full of employees from the sponsoring company, I worry that the project has not been picked up by a lot of people. But a vibrant community is a great thing because people outside the company start to take ownership of the project.

Project Lifetime & Release Cycle
Look at how long the project has been around and how often it releases code. A project that has been around a few years with regular releases is probably solid. A project that hasn’t released in five years is probably dead. I don’t mind using really new projects, you just have to be careful with them. For new projects, I put a more emphasis on the project momentum.

Project Momentum
Project momentum is probably the most important factor for me. I want to use an open source project that will be active throughout the life cycle of my development project. Otherwise you start to have the situation of supporting legacy code that no-one is familiar with. Momentum is tricky and you have to take into account the overall open source atmosphere. What trends is the industry following? What types of technologies are now hot?

A good example of this is Struts. Struts became the standard for java MVC programming a long time ago. There are a ton of projects and programmers that use Struts. But Struts is now on the way out. People have figured out ways to design frameworks that extend the functionality of struts. Would I choose Struts for a new project? No. I feel that a safer bet would be to use a newer, more up and coming framework like Spring MVC.

So evaluting your open source options is not a fixed science and involves some fuzzy math. In the end, choose a library that you are comfortable with and you think will have a longevity in the industry.

Innovate or Die

I had a Eureka! moment about why companies choose open source. They choose it because they must innovate or die. There will always be people who choose open source because it is bleeding edge and I am not talking about those people. I am talking about companies that choose open source because of a compelling business reason.

Innovation comes because of two problems: costs and features.

Most people will quickly site costs as a reason to choose open source. This belittles many of the other reasons to choose open source, but cost is a valid point. Many companies cannot pay for existing software. Just look at some of the “enterprise” type of programs and the costs are astronomical. So what is the company suppose to do, just roll over dead because it can’t buy software. NO! The company can choose open source because the initial licensing fees are now gone. Sure the company will have to support the software themselves with more sweat equity, but small companies are full of sweat equity and little cash. So these companies innovated by taking on their software responsibilities themselves.

The second way to innovate is through new features. Tons of companies differentiate themselves by the features on their websites. Do you think that these fancy features came right out of the box? NO! Many of these companies started with an existing open source project and then added new features to it. Instead of buying a proprietary system that they could not extend, these types of companies chose open source where they have full access to all the code allowing them to add features out the wazoo.

I think it is easy for small companies to fit into the innovate or die category. So selling open source to these types of companies is rather easy. Open source in larger companies is harder. With the budget to buy enterprise class software and a track record of out sourcing major projects, convincing a company to bring development in-house and use open source is a tough sell. I think if the desire to innovate is in the company, it would be easy to make the switch. If that innovation desire does not exist, put your flack jacket on because you have a long hard fight ahead of you.

But there is good news. Board rooms of larger companies are starting to feel the breeze of the open source change. They see how open source has benefited other companies and are starting to ask, “can we use open source?” And that my friend, seems like the beginning of a desire to innovate.

Open Source Enthusiasts are DIY’ers

I think that a majority of people who use open source do it because they like to DO and solve problems. They are the type of people who would rather drive around a city aimlessly instead of stopping to ask for directions. Solving the problem, at whatever cost, is a major driving force for many open source users.

Since the problem solving desire is a personality trait, it is hard to make a business case to choose open source based on your own desire to solve the problem. Managers want numbers. They want to know that by choosing open source, they will save $X or productivity will increase Y%. Maybe instead, there should be a measurement that with the right developers, choosing open source will increase morale Z%. I know that I am more happy when I work with tools I enjoy.

Increased morale is one of those touchy-feely areas. Just because you have happy employees doesn’t mean you will have a better product. But it might make the whole process more enjoyable if you don’t have cranky developers.

I think choosing open source is most effective when the whole company wants to solve the problem. If parts of the company are ready to pay a vendor mucho dinero to make the problem go away, then there will probably be friction if you choose open source. Take a look at other parts of the business like accounting or marketing. Does the company outsource a lot of work? Would the company rather pay a consultant to do a project instead of investing in more internal resources to get the project done? If you are working with an “outsourcing” minded company, then open source will probably be a hard sell unless you can prove that is saves a ton of money . But when it comes to choosing between two equally priced options, outsourcing or diy’ing, the company will probably choose the option that is more inline with the existing corporate mindset.

An Unintended Open Source Advocate

I never consider myself one to take up the torch for a particular cause. You won’t see me demonstrating infront of a government building or writing letters to my Senator. But lately I have noticed that I am championing the idea of open source to clients.

Over the years, I have used plenty of open source projects while developing websites. At first it was probably because I didn’t want to pay for MS Visual Studio. Then I didn’t want to pay for proprietery components. But I think what it really turned into was an issue of freedom.

With open source, I feel like I am in control of my project. If I want a feature that isn’t standard with a particular product, open source allows me to create that feature. I can pick and choose on the component and framework level. This lets me create the system that I WANT to use, not a system that is full of hacks to make things work the way I want.

There are tons of great projects with solid documentation and online support options. Just think of Apache, Tomcat and MySQL. These are all major players in the internet world and they are all open source. If you get stuck, just search around the internet to find your answer or you can even find places that offer paid support.

So am I an advocate? I guess so. The freedom of choice and extensibility is what I really love about open source.