Commercial Viability of OpenSource

Let me start of by saying that I’m no zealot. I don’t really care bits for beans about the difference between OpenSource and Free (the impact is the same to me as a user of the software), and I have no compunctions about going out an buying a piece of software if it is worth what I spend on it. I also believe that OpenSource products are only strengthened when companies are allowed to leverage them to make money.

I was talking to a friend the other day and their company was trying to decide whether to go with an open source project for development of their applications or whether to develop something completely in-house. The question they were asking themselves was, “Is it more important for you to have a stable API, or is it more important to claim that your software is based off of open standards.” We can all guess what the answer was.

This, however, is not a fair question. They confused having less control over a project with not being able to have stable APIs. OpenSource software can, and often does, have API’s that are just as stable as the ones developed in-house. In many cases they are more stable, especially if the OS Community you choose has a large and diverse support base. Sure, there are some OpenSource products that change from release to release, but if a company does its due diligence and finds a community where backward compatibility is important, using these products should not be much of a concern.

While the above may not have been a fair question though, I think the real question to ask is if OpenSource Software can deliver the balance between flexibility and stability that a company is looking for. Many companies have changed API’s and implementations from time to time simply because the current architecture didn’t lend itself to solving an important problem. This is especially true in XP shops which don’t pay as much attention to the longevity of a design as other development paradigms. Tying yourself to an OpenSource community makes this “balance” a little more difficult because the balance the product does not have a singular definition of what this proper balance is. I would assert, as a matter of fact, that for larger and more organized OpenSource communities, you tend to find that a project mimic’s its most conservative contributors.

So how can some of the issues of OpenSource be mitigated?

1. Research the community: As important as the functionality of an OpenSource project is the community that supports it. This is one of the most often overlooked aspects of deciding whether to use or support an OpenSource initiative. Is backward compatibility important to the community? Is the community responsive to bugs and enhancements? Is the community responsible with managing it’s releases. Is the community generally in line with your companies ideals between the balance of stability and flexibility. Especially if you are willing to become active in the community, driving functionality is easy provided the community holds the same values as your organization.
2. Become active in the community: Many OpenSource communities, like Apache, give a bigger say in product direction to those people who contribute the most to the project. It’s only fair. This of course needs to be tempered with the fact that the community must be protected from bullies (ie. companies who dedicate a bunch of resource to ‘hijack’ a community). Most programmers and managers of large community-driven projects tend to be responsible and simply want to do the right thing. The best way to protect your companies interests in an OpenSource project is to become active. OpenSource projects should not be seen by organizations as “free” software. Rather the cliche’ of “you get what you pay for” holds true. The more you put into a project, the more say you have in the project’s direction and those efforts in turn benefit the community. As such, while OpenSource may not be free, it will generally be a bargain.
3. Become Organized: The best way to limit exposures to an OpenSource community is to be organized. Have a clear understand of your architecture and identify which parts are harder for your to be flexible in then others. Let your developers who contribute to the OpenSource community have a clear understanding of your product and its direction so that they can, in turn, fight harmful initiatives in the OpenSource community. Also understand at what level you integrate with an OpenSource product and identify which areas are most important to you and your company to concentrate your development efforts.

I hope this helps somewhat and I’ll probably have more rants about the OpenSource in the future. There are many companies who have leveraged the power of OpenSource to drive their commercial goals whether those goals be industry acceptance, shared development, or cheaper infrastructure.

Good Luck!

~ by scottobryan on June 23, 2008.