How can anyone make money from software development if nobody pays for software? Chip Camden thinks the answer is to stop treating software as a product.
I've spent almost all of my 20-year consulting career working with software vendors: companies that write software in order to be able to sell it to users. These clients find their markets somewhat threatened by the rise of free software.
Back in the 80s and early 90s, few people took free software seriously. Some shareware was okay, but if you really wanted a reliable product you bought something commercially packaged and supported. That perception began to change when web browsers became available for no charge. Of course, back in those days businesses didn't need web access -- it was considered mostly recreational.
Linux presented the first credible threat to the "software for sale" model, because it demonstrated that a voluntary collaborative effort could produce something capable of replacing an important and costly piece of business functionality: the operating system. From the late 1990s until the present, more and more free alternatives have become available in diverse areas of business functionality -- from office automation (Google Docs and Mail, OpenOffice, LibreOffice) to software development (numerous languages, frameworks, version control, etc.).
Even in some vertical markets where free alternatives haven't yet flourished, the general trend towards free software has lowered the price point. Back in the 80s a decent order entry system for a company of less than 100 employees might run $80,000 just for the software (I'm quoting from memory of a real transaction I witnessed), plus more for support. I'd be surprised to learn of any SMB spending more than a tenth of that on a single accounting application these days.
I don't see any signs that this trend will abate, and I don't think it's necessarily a bad thing. Software never has fit very well into the manufactured product for sale model. Sure, the cost of creating software can be huge, but the incremental cost of producing one more copy approaches zero. Thus, the model of paying a per copy price doesn't accurately reflect the value obtained, and leads to efforts to subvert the pricing model that would never occur to someone who needed, for example, another car.
The software industry needs to find alternatives. A number of vendors have expanded the capabilities of their free/Express/trial versions so that they only exclude features that are relatively uncommon, advanced, or supporting a high volume of transactions. Users would willingly pay good money to
obtain those features if they needed them. While this approach lets a large number of users go free of charge, it provides the best form of marketing money can buy: existing users. Not only will those users buy the upgrade if they need its capabilities, but the product's larger market share will drive sales to those who don't use it yet.
That's a good approach for now, but I think it's a band-aid on a wound that runs much deeper. Eventually, nobody outside the most specialized, esoteric markets will be willing to pay for software licenses. Software companies can fight this tooth and nail, but in the long run they will lose.
So how will anyone make money from software development, if nobody pays for software? Surely, voluntary efforts can't supply all the software that businesses need. Software developers gotta eat!
The answer, I think, is to stop treating software as a product, and use it instead as part of a service offering. Don't pay me for what I've made, pay me for what I can do for you. As a consultant, I've been operating on that model for the last 20 years. I routinely (and contractually) grant my clients full ownership of the code that I write for them; they can do what they want with it. Furthermore, I don't bill them for the code -- I bill them for my time. Even though "time" does not perfectly equate to "service," it's a lot closer to it than a software license is, because it naturally includes any time I spend setting it up for them, providing support, and making further modifications.
I don't mean to say that all software providers should charge by the hour. Rather, consider that what you're providing to the user is a service rather than a product. Perhaps instead of charging for the XYZ package, you should charge for supporting it, configuring it, customizing it, and educating the users.
That still leaves a lot of unanswered questions, like "How do major new enhancements that existing users don't urgently need ever get funded?" The answers to those kinds of problems vary with the availability of working capital and the community of users and developers involved.
This may not seem like a topic specific to IT consultants. I've always said, though, that as consultants we have a duty to our clients to keep an eye on their business success. Their success supports our own, after all. That's especially true in the case of software vendor clients, where our efforts go right to the heart of their business.
Thanks to Chad Perrin, who shares my enthusiasm for free software, for suggesting this topic.