Back in the early 2000s, software customers and vendors were both excited to embrace an alternative to selling and buying applications on CDs in card-board boxes, dealing with complicated installations or upgrades, and being limited with multi-user collaboration beyond the physical office's internal network. Why bother with these hassles and limitations, if a subscription to a managed cloud service could solve it all? Why indeed, said millions of businesses, and signed up for Basecamp and thousands of other subscription software services. Thus began a twenty-year reign of SaaS dominating business software sales.
But the pendulum has been swinging between the client and the server for a long time in computing, and I think we might be at the cusp of another iteration back to where we were. The hassles of dealing with software products from the early 2000s have been understood, and at the same time, the limitations of software services in the 2020s loom much larger.
Let's look at some of the compelling reasons for why we might get a resurgence in software products at the expense of services. First from the perspective of the customer:
1) Possession in 9/10ths of the law, and with software services, you are just not in possession of your data. You may own it in that last Terms-of-Service intermediated tenth of the law, but that'll be little comfort if you lose access to it. Like if the black box at Google becomes trigger happy, and leaves you circling around the Kafkaesque maze of trying to convince the faceless Borg to let you back in.
Leaving your data in possession of others also means they can both pass it on in response to legal requests, marketing opportunities, or worse. Let alone the trouble you might face, if you displease the custodian who, in their complete sovereignty, always hold the power to have you banished. Refusing service on individual moral, political, or other grounds is something people can do when they're offering a service, not after they've sold you a product.
2) Since you can only rent continued access to the service, you'll never be in control of the upgrade schedule or the continued operation commitment. While we at 37signals pride ourselves on continuing to service applications that have been discontinued for a decade or longer, most operators do not. Google is notorious for killing services whenever they're bored or have an executive shuffle. When that happens, the best you usually get is three months to export your stuff in a data format you can't actually do anything useful with afterwards, and to the tune of We're Sunsetting This Service To Focus On Other Strategic Areas.
A lesser version of this happens when the service you're relying on decides to launch a mandatory makeover. Ta-dahhhh! The service you were perfectly happy with five minutes ago is now totally alien to you, all the functions have been moved around (and probably hidden in a burger menu), and we hope you'll love it as much as the designers who arrived here yesterday!! Isn't progress fun?!
3) You can't just like what you see, pay once for the product, and continue to live happily ever after. Somehow we've all, buyers and sellers, swallowed the logic of planned obsolescence when it comes to software. That unless it keeps growing bigger and different, it's apparently dead. Why?
Most business software is bought because it serves a purpose. It's a tool, not entertainment. Novelty ought not be a top priority. It shouldn't need to constantly absorb continued effort for years after it's created.
That's not to say that there aren't benefits to new versions, new features, and bug fixes. Of course there are. But these benefits do not have to face the challenge of the market, having to justify another sale. They're simply accepted as defacto blessings in all circumstances, even though they're obviously not.
I, for one, would be very happy never to upgrade the firmware of my printer, I don't need any additional features for iA Writer, and I'm still pissed that I can't purchase Adobe Lightroom rather than pay a monthly subscription for it.
I wish there was a broad category of software that was offered in its final form. The Maximum Viable Product. Software products that I could continue without change for as long as they will run on the hardware they were made for.
So those are some of the reasons why customers might come to realize that the switch from software products to software services wasn't without serious trade-offs. And they may begin to contemplate whether they wouldn't actually prefer to start buying the former again, if anyone would offer them.
But software services also incur serious trade-offs for software makers. Gone seem the days where you could just be a pure business product company, full of folks dedicated to the task of creating software, rather than operators needed to service one master installation 24/7. So let's examine a few of the reasons why some software makers might also want to return to the days of the software product rather than continue to run a service:
1) Running a software service that has thousands of customers means you're the single point of failure for their dear data. If your service goes offline, nobody, anywhere can get to their data. Even a few minutes of downtime can seem bad when tens of thousands of customers can't access the critical information you hold about their business. A few hours might well be catastrophic.
To mitigate this risk, most large software service vendors have enormous operations teams. People on-call with the obligation to wake up in the middle of the night if something is wrong with the service.
And it's even worse for smaller operators. In the early days of Basecamp, I had to travel everywhere with my laptop, and I spent more than a few vacations outside of the hote trying to diagnose and resolve a production problem.
2) You can't just make something and move on. All the revenue in services is in providing continued operations. The lifetime value of a subscription customer is spread out over many months or years. This is of course both a blessing in terms of the predictable cashflow, but also a curse in terms of the obligation to work on the same thing forever.
Which means invariably tinkering with, changing, and enhancing that same one thing forever. Since part of the service obligation is that customers continue to be "delighted" with changes that they get for "free" as part of their subscription. The software just keeps getting better (or not)!
But there's a reason many software makers pine for the rare opportunity to work on greenfield projects. That lush open space to start fresh with your best ideas, unencumbered by old promises and old decisions, is invigorating. Yes, there are lessons in legacy, but probably more in new attempts.
3) The kind of organization that's really good at keeping an existing thing going with as little drama as possible is often quite different from the one that lit the fireworks to begin with. Sometimes that's different-good, but sometimes it's surely also different-bad.
When I read tales of what the early video games industry was like, I certainly get some pangs of envy. Imagine getting to work on something entirely novel every 18-24 months, with a small team entirely focused on a single creative endeavor. (In other regards, like the endless death marches that historically has entailed with game development, I perhaps wouldn't be such a big fan, but hey, trade-offs!)
Point being that in the video game industry, there historically was a focus on separating out the creative process from the supporting one, and placing it in separate organizations. You had the creative studios optimizing for what they do best, and then you had the publishers optimizing for supporting and bringing that to market. A separation of concerns that I think had a lot of wisdom to it, even if it's actually also become a lot rarer with modern video game development.
For all of these reasons above, alongside the dramatic ease that technical breakthroughs like Docker has made to ease the distribution of business software, I think, or at least hope, that we'll see a resurgence on the product focus in the 2020s and beyond.
I dream of being able to both buy and sell finished business software products.
But the pendulum has been swinging between the client and the server for a long time in computing, and I think we might be at the cusp of another iteration back to where we were. The hassles of dealing with software products from the early 2000s have been understood, and at the same time, the limitations of software services in the 2020s loom much larger.
Let's look at some of the compelling reasons for why we might get a resurgence in software products at the expense of services. First from the perspective of the customer:
1) Possession in 9/10ths of the law, and with software services, you are just not in possession of your data. You may own it in that last Terms-of-Service intermediated tenth of the law, but that'll be little comfort if you lose access to it. Like if the black box at Google becomes trigger happy, and leaves you circling around the Kafkaesque maze of trying to convince the faceless Borg to let you back in.
Leaving your data in possession of others also means they can both pass it on in response to legal requests, marketing opportunities, or worse. Let alone the trouble you might face, if you displease the custodian who, in their complete sovereignty, always hold the power to have you banished. Refusing service on individual moral, political, or other grounds is something people can do when they're offering a service, not after they've sold you a product.
2) Since you can only rent continued access to the service, you'll never be in control of the upgrade schedule or the continued operation commitment. While we at 37signals pride ourselves on continuing to service applications that have been discontinued for a decade or longer, most operators do not. Google is notorious for killing services whenever they're bored or have an executive shuffle. When that happens, the best you usually get is three months to export your stuff in a data format you can't actually do anything useful with afterwards, and to the tune of We're Sunsetting This Service To Focus On Other Strategic Areas.
A lesser version of this happens when the service you're relying on decides to launch a mandatory makeover. Ta-dahhhh! The service you were perfectly happy with five minutes ago is now totally alien to you, all the functions have been moved around (and probably hidden in a burger menu), and we hope you'll love it as much as the designers who arrived here yesterday!! Isn't progress fun?!
3) You can't just like what you see, pay once for the product, and continue to live happily ever after. Somehow we've all, buyers and sellers, swallowed the logic of planned obsolescence when it comes to software. That unless it keeps growing bigger and different, it's apparently dead. Why?
Most business software is bought because it serves a purpose. It's a tool, not entertainment. Novelty ought not be a top priority. It shouldn't need to constantly absorb continued effort for years after it's created.
That's not to say that there aren't benefits to new versions, new features, and bug fixes. Of course there are. But these benefits do not have to face the challenge of the market, having to justify another sale. They're simply accepted as defacto blessings in all circumstances, even though they're obviously not.
I, for one, would be very happy never to upgrade the firmware of my printer, I don't need any additional features for iA Writer, and I'm still pissed that I can't purchase Adobe Lightroom rather than pay a monthly subscription for it.
I wish there was a broad category of software that was offered in its final form. The Maximum Viable Product. Software products that I could continue without change for as long as they will run on the hardware they were made for.
So those are some of the reasons why customers might come to realize that the switch from software products to software services wasn't without serious trade-offs. And they may begin to contemplate whether they wouldn't actually prefer to start buying the former again, if anyone would offer them.
But software services also incur serious trade-offs for software makers. Gone seem the days where you could just be a pure business product company, full of folks dedicated to the task of creating software, rather than operators needed to service one master installation 24/7. So let's examine a few of the reasons why some software makers might also want to return to the days of the software product rather than continue to run a service:
1) Running a software service that has thousands of customers means you're the single point of failure for their dear data. If your service goes offline, nobody, anywhere can get to their data. Even a few minutes of downtime can seem bad when tens of thousands of customers can't access the critical information you hold about their business. A few hours might well be catastrophic.
To mitigate this risk, most large software service vendors have enormous operations teams. People on-call with the obligation to wake up in the middle of the night if something is wrong with the service.
And it's even worse for smaller operators. In the early days of Basecamp, I had to travel everywhere with my laptop, and I spent more than a few vacations outside of the hote trying to diagnose and resolve a production problem.
2) You can't just make something and move on. All the revenue in services is in providing continued operations. The lifetime value of a subscription customer is spread out over many months or years. This is of course both a blessing in terms of the predictable cashflow, but also a curse in terms of the obligation to work on the same thing forever.
Which means invariably tinkering with, changing, and enhancing that same one thing forever. Since part of the service obligation is that customers continue to be "delighted" with changes that they get for "free" as part of their subscription. The software just keeps getting better (or not)!
But there's a reason many software makers pine for the rare opportunity to work on greenfield projects. That lush open space to start fresh with your best ideas, unencumbered by old promises and old decisions, is invigorating. Yes, there are lessons in legacy, but probably more in new attempts.
3) The kind of organization that's really good at keeping an existing thing going with as little drama as possible is often quite different from the one that lit the fireworks to begin with. Sometimes that's different-good, but sometimes it's surely also different-bad.
When I read tales of what the early video games industry was like, I certainly get some pangs of envy. Imagine getting to work on something entirely novel every 18-24 months, with a small team entirely focused on a single creative endeavor. (In other regards, like the endless death marches that historically has entailed with game development, I perhaps wouldn't be such a big fan, but hey, trade-offs!)
Point being that in the video game industry, there historically was a focus on separating out the creative process from the supporting one, and placing it in separate organizations. You had the creative studios optimizing for what they do best, and then you had the publishers optimizing for supporting and bringing that to market. A separation of concerns that I think had a lot of wisdom to it, even if it's actually also become a lot rarer with modern video game development.
For all of these reasons above, alongside the dramatic ease that technical breakthroughs like Docker has made to ease the distribution of business software, I think, or at least hope, that we'll see a resurgence on the product focus in the 2020s and beyond.
I dream of being able to both buy and sell finished business software products.