Use Open Source To Save Money

FOSSBazaar is no longer being updated. The information on this site is preserved for your convenience but may be out of date. Please visit Linux Foundation's Open Compliance Program for current information and activities.

Phil's picture

Matt Asay’s blog entry on Feb. 26 calls into question OpenLogic’s business methods of offering FOSS support and lifecycle management. He refers to this practice as “skimming the fat” off the top of the open source community. I don’t see it that way and here's why.

Open source software is an example of a user-driven innovation network. These are defined by large groups of people working on some common goal. The internet has become a new and very profound facilitator for this type of network, and FOSS is the best example of a user-innovation network to date.

The key to user-driven innovation is *the user*. The open source movement came about because users, for a variety of reasons, chose to initiate a development project to fill some need that *they had*. Then, they threw the code "out there" on the internet for others to use *freely*. The power of this process can be seen as others pick up the code, and develop it further to fit their own needs. The aggregate results are open source projects that rival commercial products in features, performance, and flexibility.

HP's open sourcing of FOSSology is a perfect example of this. HP needs to understand licensing and other characteristics of the FOSS that we use and distribute. We built FOSSology as a tool to help us with that. We can see many other valuable features that could be added to FOSSology, but we have limited resources for this effort. We also know that there are many other organizations out there that have the same needs as HP regarding their understanding of FOSS. By open sourcing FOSSology, we let others add to our work, making it more valuable to both them and us. As with most user-innovation networks, 95% of the users of FOSSology will never contribute anything back to the project. Three to four percent will post bugs, and possibly a bug fix every now and then. Two percent (or less) will actually provide consistent bug fixes, and enhancements to the project. I think this is common for an open source project and should be expected whenever you initiate one.

Many people have asked the question "how do I make money on open source?". To date, that question does not have a good answer. That's because it's the wrong question. The right question that people need to ask is "how do I *save* money with open source?". This is a much easier question to answer because it can be shown by the 1000s of man hours your development team didn't spend writing some technology that was available as open source, or the lack of royalty fees paid for commercial software licenses. With that said, then what is "Commercial Open Source" and why would anyone use it?

As I stated in my blog Tying a Bow on Open Source, there are many things beyond the code that can make FOSS more consumable for many users. These include but are not limited to:
Commercial Support
Improved Documentation
Integration Testing
Stack Lifecycle Management (tested and secure software updates)
Sales aids (case studies, data sheets, product brochures, etc)

Adding or augmenting these features to an existing open source project bring value to the project and their users.

From working with customers, I have found the following 3 general types:

Do-It-Your-Selfers - These users have their own development staffs and they are comfortable with the FOSS they use. They can find, and fix bug, as well as add enhancements if they need to. Given the amount of FOSS that everyone believes is in use today versus the commercial revenue received, I believe that the vast majority of FOSS users today fall into this category.

Commercial Support and Lifecycle Management Needed - This group of customers have developers comfortable with the FOSS technology, but a production team that is not. By having an organization provide the open source stack components pretested on the front end, and supported on the back end, the production team can deploy with confidence.

I Only Understand Commercial Software - This group want a product that does as much and costs less than the competition. They are not part of the "user innovation network". They don't want to understand or modify the code, they just want it cheaper... and less vendor lock in is a plus.

From my perspective, OpenLogic is addressing both the first and second type of customers/users. If those users want a major enhancement to a FOSS project, they will do it themselves, or they will hire someone like OpenLogic or another outfit to create that enhancement for them and put it into the community. This is how the open source code gets replenished in this model.

For the companies that are addressing the third type of user, they don't really even need to open source their code. If they do, then they can try to generate a developer community around their product, and they can hire some of the lead developers to ensure that the project continues at a good pace and goes in the direction that the company wants. However, they should not be unhappy when others take and use their code without providing them monetary compensation (remember the 95% number mentioned above). Also, they should not be unhappy if other companies join their FOSS project and begin to offer support for their technology. If the founding company want's to protect against such behavior, then they should use a non-opensource license such as a "shared-source" and/or a Freeware-type license. But of course if they do that, then they miss out on the cachet of being an "Open Source" company.

I agree with you Phil

What I would add to your comments, but focus on the "support" side of the equation. I would start by saying .. "Just because you want something to go away, doesn't mean everyone else does." What does this mean? At the CORPORATE LEVEL (which I have a fair amount of experience) there is YEARS of experience and expectations around supporting and migrating software. The issue is, when something breaks and the user is screaming, the Operations team usually has a process of support and/or escalation they can rely on. The base Open Source Model is VERY different - and some companies just aren't comfortable with it. 1. There is an EXPECTATION that when something breaks there is someone there to support/fix it - AND to make sure that doesn't happen again. This is the proverbial "One Throat to Choke" In the Open Source field, that means that the person providing the support has committer status. There is significant value in this, as it is doubtful that the average company has staff that is that actively involved in the underlying projects. 2. There is an EXPECTATION around the packaging of software. The expectation is that you downlod it, install it and use it. Open Source projects TYPICALLY don't focus on the "Commercialized" issues surrounding their products - Some do - but most don't 3. There is an EXPECTATION that there is help to get from 1 version to another. Take a look at major software companies that produce migration documentation to get you from the OLD version to the NEW version. How many Open Source projects do that ? The point here, is that there is a need for companies that provide this service. These "requirements" don't go away just because its "Open Source"