Nice Cage For Rent

Someone once said that open source software is free, like a puppy.

There’s truth there. All software must be maintained with security patches, enhancements, and bugfixes. All software costs time and effort to integrate into your IT environment, and to adapt to your business processes. There is a learning curve.

When you think about it you discover that open source software shares many of the same costs with off-the-shelf proprietary software. The phrase to keep in mind is TCO or “total cost of ownership.”

In this article I will focus on the proprietary software business model. The proprietary model is based on selling many identical copies of the same package. To facilitate integration the software is configurable, possibly having network interfaces and a plugin architecture.

The vendor makes their money on the difference between their costs, and the license fee paid by the customer. The costs are various allocated overhead, developers salaries, and anticipated technical support costs.

Support Cost

The first problem you recognize: in the purchase price of the software, you are paying for support whether you use it or not. That’s ain’t fair! Or is it… you pay for various kinds of insurance whether you use it or not. The idea is to avoid being hit with a big bill when the unexpected happens.

So maybe that prepaid support is worth it. My experience has been that, if you don’t have a significant problem, and your time is cheap, this support can be good enough.

Personally I have found it is never good enough for people who know anything about software. I have only on rare occasions considered making a support call… I google the problem, call a buddy, or hire a consultant to come and resolve the problem. In fact, the only support calls I have ever made have been for services… internet access, telephone service, etc.

Why don’t I use the pre-paid support? Simply put, it is strictly not in the vendor’s interest to spend any time helping me. Unlike services, at this point they already have all the money they are going to get from me, for the immediate future. Aside from possible up sell of additional features during the support call (unlikely), their goal at this point is to keep their post-sale costs (potential liabilities) to an absolute minimum. They want to service my call with the cheapest support that will get me off the phone as quickly as possible, in a way that won’t upset me enough to remember when upgrade time comes around.

If I am persistent enough I can wade through level 1 and level 2 support and get someone who can actually resolve my problem. But you can bet it is going to cost me to get there… in time spent on the phone going over the problem again and again, with several email threads with things to try, often with multiple support agents who each need to rehash the problem.

So, that prepaid support has some value, but I’d give it a low number. Add to that the fact that I almost never use it, and the value seems dubious.

Development Cost

The other big cost you are paying for when you buy software licenses is the development costs. Clearly someone needs to pay that. Developers have to eat and support their families, and you’re willing to pay to get functionality you need, right?

Here, it’s not clear at first whether we’re overpaying or not. By spreading development costs over many thousands of license sales, we will certainly get a better price than if we had commissioned development of the software ourselves. Also, the risk has already been taken by the developer, and they’ve delivered a product that, let’s give the benefit of the doubt, will do the job it claims to do once we get past the inevitable learning curve and installation snafus.

On the other hand, how many times over will that license fee be paid, and by how many? How many times over has the world paid for the core Win32 API, or Word, or Excel, vs. what the actual developers that did the work got paid? That’s a cost in real resources that if not for that cost, could be devoted to other things. And it enriches a few, which would be fine, if the benefit to the rest of us were proportionate. How could a fair market create such a situation? Well, it isn’t a fair market. Copyright and software patents create artificial monopolies that favor software vendors. And, there are natural monopolies too.

We shouldn’t begrudge software vendors their reasonable profits. They invest a lot of cash and take real risk when they bring a new product to market. But as we can see with the software behemoths of the world, it can get out of hand.

One other issue to mention: lock-in. There are natural monopolies involved in the software business. It is a significant cost to switch away from one product to another. There are always devious plans afoot to make sticky features that are hard to switch away from. But even without them, the inherent complexity of software makes switching costs inevitable.

If there is some choice in the particular niche, you can mitigate lock-in even in proprietary software by buying software that adheres to open standards. But beware vendor extensions on those standards, especially with scary license terms around those extensions. The lock-in factor comes right back as soon as you become dependent on vendor extensions.

When you pick a software product, you are in a sense, acquiring a comfy spot in a cage. With payware, you are throwing in a security deposit and a few months rent up-front. You will be locked-in to the product. If it always does what you want, that lock-in may be a cost you’re willing to bear. In that case, you have yourself a well-decorated cage and you won’t notice the bars most of the time. Unlike a prison, you can always buy yourself out of the cage with switching costs, so it’s not the end of the world.

Alternatives

Up until the 1990s, this was the way of the world. You had no choice. Well, that’s not true… we used to have a lot more choices in every niche, albeit, all proprietary. But today, in most important areas within the proprietary domain we don’t even have that kind of choice.

The market has come up with an alternative, and you already know about it: “open source” and “free software.” The idea is that developers produce software, most of the time for pay, just like with the proprietary model. In this model though, you get the source, and can redistribute it, make any changes you’re willing to afford to make, and copy it, among other things.

Next time, the ins and outs of open source software, and why it is an important alternative to proprietary off-the-shelf software.

Weird Contractor

I’ve been a software developer for about 12 years now, and a software contractor for the last 6 years or so. I’ve seen a lot of strange behavior in that time.

I’ve seen cube farms full of contractors billing it up while they are really browsing Dice. I’ve heard the typical “yes, absolutely, we can do it” when the thought behind it is you’re crazy, this project is a dumb idea, doomed to failure, but we’re happy to fail at whatever you like as long as you pay your bill.

And I’ve come to the realization that many real engineers view all software contractors in this way. Hired guns that don’t really care whether their customers succeed or fail as long as they can extract some cash in the process.

One of my friends made the comment that “John is a weird contractor.” I think he was summarizing past observations of strange behaviors when interacting with customers like

  • Telling customers “no, that’s a dumb idea, but what about this…”
  • Writing myself out of the equation by fully documenting, internally and externally, the code I write, to the extent that the customer should never have to call me again once I’m done
  • Making applications that are easy for the customer to configure, too
  • Walking away from great revenue opportunities on unchallenging, uninteresting projects, or where the customer isn’t quite ready to fully utilize me as a resource
  • Pushing open source code over closed source proprietary code

In short, I exhibit the strange behaviors of brutal honesty, avoiding boring work and keeping customers from being locked in to my services in any way. Typical programmer behaviors, I suppose, but weird for a contractor.

But is it not a rational approach? Don’t customers want a solution that doesn’t lock them in? Won’t it benefit a manager for me to say “sorry, I am reducing my presence on this job since it appears with just a little better management you could get by without me.” Brutal, but that manager is more likely to keep his job than if he keeps throwing cash down the development money hole.

Perhaps these behaviors are just side effects of character “features” I have anyway, but in the long run I think they pay off more than short-term profit maximization.

I think these strategies set my services apart, and my goal with the new DevWrights venture is to build a scalable contract software development and support business around the principles of Zero Lock-In, Brutal Honesty, Win-Win or Walk Away, Always Learning, and Building Long Term Value for the Customer. Win-lose or win-I-don’t-care seems to be a widespread perception of contract software developers.

Hopefully DevWrights can change that, help build value for our customers while winning in the marketplace ourselves.

Root for us, come work for us, or let us add value to your business. We’re going to build an army of weird contractors at DevWrights. We’re out to change this industry for the better.