Buy vs. Build

I was talking to a potential client the other day and the question of “buy vs. build” came up.

I have been saying for several years now that software (all software) will eventually become either open source or a commodity product. The days of expensive “enterprise” software will be over, perhaps not tomorrow, but within the next ten years.

But the “buy vs. build” decision won’t go away. Organizations will still have to decide if they want to try and purchase the software to solve a particular problem (the commodity side) or do they want to build their own solution (using open source).

In the past, “build” meant to build the system from scratch and “buy” included taking off-the-shelf software and configuring it to work in the environment. With the increased popularity and power of open source software, it has become a whole lot easier to build a solution in house (since one doesn’t have to reinvent the wheel), and with the availability of broadband networks, the buy solution now includes outsourcing the whole thing to another vendor.

So I’m talking with this client and it was really hard to determine if OpenNMS would be a good fit. Since we are a services company, going through our sales process is a bit different than with buying software. If you buy a piece of software and it doesn’t meet your needs, the vendor still profits, as does the salesperson, so they have the incentive to sell as many licenses as they can to anyone they can.

With our business model, if we try to put OpenNMS into a place where it doesn’t belong, we just end up doing tons of support. Compared to a situation where OpenNMS is a good fit, these clients would end up costing us money. While we like money and money is good, it is not worth forcing OpenNMS to fit where it doesn’t.

There are several factors that go in to the buy vs. build decision for a management solution, and often it is not possible to determine them on a phone call. Size plays a big role, as a small organization, especially one without a technical focus, is much better off either outsourcing the whole thing or buying a basic solution like WhatsUp Gold. Larger institutions should opt for something like Solarwind’s Orion or if they are heavily Windows focused, Nimsoft’s Nimbus.

But for many larger organizations and especially those at the carrier level, the business network is so unique that no off-the-shelf product can be made to scale or to fit their business processes. For them there really isn’t a “buy” solution, although in the past the enterprise software vendors have tried to sell one.

But size isn’t the only factor, nor is it even the main one. The true measure of a buy vs. build decision comes down to your people.

I’m not sure when “people” became a bad word, but as far back as I can remember companies have been trying to reduce the number of people in their IT departments. Perhaps it was because they had a roomful of “screen monkeys“, or perhaps it was because, especially during the bubble, anyone in the industry was very expensive. But in my experience having a few good IT folks coupled with the right tools is the best way to manage your information infrastructure.

But how to do you ask that on a conference call? How do you ask “Hey, do you have anyone on your staff who really enjoys solving problems with technology and they have the skills to take something like OpenNMS and run with it?”

If you read our Order of the Blue Polo testimonials (keep ’em coming) you’ll see some that praise the “ease of use” of OpenNMS. While I find OpenNMS extremely easy to use, our biggest criticism is the learning curve. Yet there are people talking about how easy it was to get running. The only conclusion I can come to is that OpenNMS users are just smarter, more hard working, witty, and physically attractive than your average IT person (grin).

Those organizations that choose “build” and have the staff to pull it off will be the big winners. I saw a great post yesterday on The True Cost of Migrating to Open Source. Mark Taylor presents a solid argument that the cost to migrate to a free and open solution (as opposed to a shareware, open core, neo-proprietary, or “commercial” open source solution) is the same as migrating to another proprietary product, yet the long term cost savings are great. While I’m sure this will get him labeled as some hippy purist, it is hard to argue with his conclusions.

I just wish the buy vs. build conclusion was as easy to reach.

One thought on “Buy vs. Build

  1. I really consider open source as somewhere in between buy and build, you have the option to treat it either way. You can use it “as is” like you would in a buy scenario, or you can customize it as you would in a build scenario. There are several ways open source is not like either though, that can be advantages to it.

    OpenNMS continues to deliver well on both scenarios. In my environment we have used OpenNMS in a largely “as is” state, mimicking buy. We have from time to time modified OpenNMS, but shared our modifications back into the project, this is another advantage to open source over buy/build. As end users modify the project to work best for them, their efforts can be shared. They don’t have to share, and I bet less than half of the modifications made to OpenNMS make it back into OpenNMS.

    There are buy/build hybrid models out there where the end user has access to source and can customize the product. However, sharing their customizations is difficult, if not impossible. Open source by default makes this easier, both in that it is in the best interest of the project to accommodate community submissions and by just the fact that it is open.

    A mechanism to share modifications could be, and to some extent is being, adopted by the closed source world. In particular, we see the open core companies trying to make this work to their advantage. The key issue is that they still need to sell licenses, and if a feature from the community is more marketable than the for fee feature, they will have a moral dilemma. Do they stand by their openness? Or do they yield to their need to sell licenses?

    Puppet is another excellent example of open source working. However, keeping the faith can be difficult. I’ve followed some of Reductive Lab’s efforts to find a way to preserve their ability to make money yet remain open. They are looking at models similar to OpenNMS. Some have worried that this would change attitudes towards sharing code. The difficult part is that some people view any kind of control as impeding openness, but without some, open source would never evolve.

    Very few applications can survive on the community alone. At the core there needs to be some people who can make a livelihood from the project. In order to do this, some cover needs to be provided for them, otherwise the risk to their livelihood is too great. Things such as a contributor agreement, and copyright work to provide this. Those making money can then be assured no one will take their work and profit on it without abiding by the GPL in OpenNMS’s case.

    It is still a new frontier, and there will be missteps, but to me this seems like the right road.

Comments are closed.