Software Through the Ages

A product in the past, a service in the present, a tool in the future

Software is becoming more and more crucial to modern life. Companies are using software to be global superpowers that redefine almost every aspect of society. That’s why it is worth taking some time to look at the history of the software business, to see how it has evolved, and to think about what may come next.

In this analysis, we are going to look at the way software is packaged and distributed, skipping over the technical details of programming languages, operating systems, and architecture paradigms. We expect the reader to be familiar with software to a certain extent, knowing how to use software on a laptop and mobile device. While we may get a little technical about some of the jargons and product names, they are not necessary for understanding the overall evolution of software distribution; including the way distribution channels impact the type of software that is created, plus the places where value and power are accrued.

Here’s a quick outline of what we are going to discuss, as we talk about the software distribution paradigm; the order of discussion points is roughly chronological to the peaks in market power.

1. Software-as-a-Product (SaaP): peaked in 1995 with the launch of Windows 95 and Microsoft Office 95, then again in 2005 with the launch of the App Store by Apple
2. Software-as-a-Quote (SaaQ): peaked around the start of the millennium with Web consulting and offshoring, then transformed into agile software development
3. Software-as-a-Resource (SaaR): peaked in 2005 with Google Search
4. Software-as-a-Service (SaaS): currently peaking with Zoom / Slack / Salesforce, etc.
5. Software-as-a-Tool (SaaT): an emerging pattern enabled by open-source development, including shared developer tools and packages

We will talk about how each of these patterns evolved into the next one, which problems each successive evolution solved, and which downsides they introduced.

Before we jump in, it is worthwhile to look at the word “software” and contrast it with the word that came before it, which is “hardware”.

For the most part of the computer revolution, companies that created the actual computer hardware, timeshare machines, and mainframes — dominated by IBM, UNIVAC, and NCR — sold their hardware with the anticipation that the software was something you would write yourself. That means people used punch cards to automate certain types of business processes; and you didn’t really sell those punch cards, just like you wouldn’t sell your index cards or notebooks.

As computers became smaller, hobbyists started to buy them in order to play with them. The computer that got Bill Gates started was the MITS Altair 8800 — a computer you programmed by flipping switches at the front of the machine. That was the software for Altair — the sequence of switch flipping that began the software revolution.

In 1975, young Bill Gates created Altair BASIC, an interpreter for the BASIC programming language to run on the MITS Altair 8800, together with Paul Allen. BASIC allowed personal computers like the IBM PC to be more easily programmed for special tasks, as it used English words to give instructions to the computer, thus didn’t require a deep understanding of the machine code or assembly language.

Software as a Product

There is no doubt Bill Gates was a great programmer, being able to make BASIC run on computers that had no more processing power than a pocket calculator. But what was most brilliant and radical about Bill Gates’ vision for computing was that the programs you wrote (using programming languages like BASIC) could become products you could sell in a tangible way. The software was packaged into boxes, including manuals, and sold in retail stores, where you could purchase them the same way that you bought a toaster or a book. In exchange for your money, not only did you get the actual media (which started out as floppy disks, then became CD-ROMs and DVDs); you also acquired a license to use the software. What you were buying was not actually the program, but the right to use the program, along with the method to install it on your computer.

When you distributed software using physical media like floppy disks and CD-ROMS, you needed to create a final version of the software (a golden master or GM) to be replicated for retail copies. This means that any updates to the software, which were made after the product had been manufactured, would require another product, sometimes called an “upgrade edition”. That upgrade contained the full program, so that you could install the next version; at which point you only had the license to use the new version. This full-version upgrade cycle drove Microsoft’s growth from a small software company based in Redmond, Washington, to one of the most valuable and influential companies in the world.

GETTY IMAGES/AFP/TORSTEN BLACKWOOD

The peak of this model was in 1995, when Windows 95 and Microsoft Office 95 were released with great fanfare around the world, causing lines to form outside computer stores that were not seen again until the launch of Apple’s iPods and iPhones.

The model of Software-as-a-Product faded away for about a decade, as people used the Web for downloads. But it became resurgent when Apple — with their iTunes e-commerce model, where you paid per download — introduced the app store. In no time, thousands of apps were released for the iOS platform, with some of the nicer ones requiring you to pay $2.99 to $9.99 to use them. Steve Jobs’ obsession with user happiness eliminated the cumbersome and extractive upgrade business model Microsoft had pioneered and profited from for all those years.

Instead, the idea was: You buy an app from the app store once; then you are guaranteed to get free updates to all future versions of the app. This was lovely for consumers. But it created a real dilemma for software developers, who had to maintain these iOS apps, making sure that they were compatible with the latest version of the operating system and could take advantage of new features on people’s hardware devices. As a consequence, most developers moved away from selling their software as digital products on the app store. They began to use the app store as a distribution channel only, so as to get the icons of their free (because advertising-supported) or paid (because subscription-driven) products into the users’ devices.

Software as a Quote

In parallel to the consumer adoption of desktop software (and later mobile software), enterprises began to take advantage of the cost efficiency of moving their processes to an electronic workflow. More and more off-the-shelf software became available for purchase (e.g. accounting, HR, and IT management software), starting with Windows-based enterprise apps and then moving to Web-based versions of the same apps.

However, as it turned out, these off-the-shelf apps only worked well if they were connected with each other, integrated with the company’s existing system, and customized for the specific needs of the business or vertical industry. Software-as-a-Product, however polished and complete, was not enough to transform a business; multiple products had to be integrated to fit those unique requirements.

As a result, to roll out a new business application, companies often spent 50% of their budget on licensing software products from companies like IBM, Microsoft, and Oracle, while allocating another 50% of their budget for software consultancy and system integration (offered as a staffing service).

Within this paradigm of software being created based on a quote, there was an evolution away from the waterfall model, where the requirements were specified upfront, after which several sequential steps — system design, implementation, testing, deployment, and maintenance — had to be completed one after the other in a fairly rigid step-by-step manner.

Later, this evolved into a more iterative, agile software development model, where the software did not need to be defined and quoted upfront. Instead, you just quoted the amount of resources needed (e.g. the number of developers on the project) as an ongoing cost; then, you planned the feature development, which was based on the continual analysis of what had been built thus far and what the business stakeholder liked to see extended or modified. You fixed the time and resources and flexed the scope.

For the purpose of our understanding of the distribution model, it doesn’t matter whether the Software-as-a-Quote approach was carried out according to ISO standards or agile techniques. What we need to know is that the proliferation of custom software integrators created a new software distribution channel, where new products and services could only gain a foothold in the enterprise market if they came with a trained pool of consultants who knew the product and its capabilities well. They needed to come in to not only sell the software and licenses as a value-added reseller (VAR), but more importantly, to make it work in the real corporate IT environment of big or small companies in the US or around the world.

The main drawback of Software-as-a-Quote was the huge cost of building the same thing over and over again. As companies became more cost-sensitive towards these custom system integration projects, they started looking for cheaper development resources offshore. That gave rise to companies like Infosys and Tata Consultancy Services, who grew tremendously with the large pool of technically competent individuals in India.

But as anybody who builds software knows, adding more people to a software project doesn’t necessarily make it go faster. In fact, the more people you add, the more communication overhead you introduce. Finally, these customizations that were touted to solve all business problems turned out to be counterproductive. Almost instantly, they became legacy code — which was software that, once built, was not easy to maintain, e.g. because it had been built on a version of a product that was no longer supported, or worse yet, it had been built by a team that had since moved on to different projects and could not provide any long-term support beyond the minimal effort of keeping the software running.

It was in this climate of frustration with proprietary software — and its endless cycle of statements of work to build and extend this so-called off-the-shelf software — that a former executive from Oracle, the kingdom of enterprise software salespeople, Marc Benioff, left Oracle to start Salesforce.com. His mantra was “No Software”, which memorialized how frustrated enterprise customers were at this time, feeling trapped by the combination of Software-as-a-Product and Software-as-a-Quote. His insight was that the World Wide Web, though still nascent (with primitive graphics and responsiveness, due to the browser technology at the time), would be able to replace millions of dollars of companies’ investments in the previous generation of client-server applications. We will return to a deeper analysis of Software-as-a-Service in a later chapter.

Software as a Resource

Before the Web became a distribution channel for software, enabling a whole generation of Software-as-a-Service businesses, it was a distribution channel for content.

At the core of the concept of the Web is the construct of a hypertext document. The markup language for creating these hypertext documents is HTML, which literally stands for Hypertext Markup Language. To access and read one of these hypertext documents, you use a Uniform Resource Locator (URL). Interestingly, Tim Berners-Lee, the inventor of the World Wide Web, originally proposed something called Universal Document Identifier (UDI); but after he circulated the idea in the Internet engineering community, he realized that he was wrong with all three words:

• It can’t be “universal”, but it can be “uniform”, because the way to construct this pointer follows a very systematic process.
• It is not really a “document” you want to access, but a “resource”. A resource could be a document, but it could also be an image, a video, a machine, or a record in a database.
• Instead of being an “identifier”, which requires some sort of scheme for registration and lookup, it should just be a “locator”, which allows someone to simply find something through the connectivity of the Internet.

The concept of the URL enables users to specify an instruction for a computer, which then points to resources that are not just simple HTML documents in a file system.

One of the first versions of software-generated resources was the CGI-BIN technique, which stands for Common Gateway Interface. A Web server, instead of fetching an HTML document based on the matching file name, could forward the request of that URL to a binary program (hence the “BIN” in “CGI-BIN”). That binary application could do whatever was necessary — access a database, run a computation process to generate images, or call another network protocol to fetch some remote data. In turn, a resource that looked like it was created by hand, using HTML.

CGI-BIN turned the Web into a software distribution platform; but instead of accessing the software directly, you were accessing the resource generated by the software in this open network of the Web. Early content management systems used CGI-BIN and its future iterations, like PHP, to create dynamic, Web-accessible resources, which hid the often complex software that was running in the background to create these linked hypertext document representations.

In early-Web software, there was often no gatekeeping between the resource generated by a dynamic program and a file that was just posted on the Web; which means that most resources were publicly accessible. To find these resources, people surfed the Web and followed links that had been curated by webmasters like Jerry Yang and David Filo, who had created Yahoo!. This hierarchical link directory now allowed people to access resources that hadn’t been available in electronic form before. But quickly, these directories became difficult to navigate. They were often incomplete or led to broken links, because a resource had been moved to a different location, which had changed the precise locator called the URL.

Because of that, people started relying on search engines, which displayed all the links they could find on the Web and provided an up-to-date index of where everything was, based on keywords. All the resources brought to the Web via software become available through one entry point: Google Search. That put Google in an extremely powerful position. Now, they could decide which of the thousands (or millions) of resources containing certain keywords would be presented as the top results on the first page.

Since all resources were publicly accessible, the only real business model for Software-as-a-Resource — where traffic was largely generated through Google’s referrals — was advertising. Each visit from a user was worth a certain amount of advertising dollars. Recognizing this opportunity, Google introduced its own advertising products, such as Google Adsense, which displayed contextually relevant ads on a Web page and paid the publishers based on traffic. Google also purchased DoubleClick, which was the leader in display advertising (more commonly known as banner ads); now, brands who wanted to get their products and logos in front of users could pay a premium on websites that had the right audience.

One of the great characteristics of Software-as-a-Resource was that all resources became archivable, which allowed Google to show a cached copy of a Web page, even if the website was down temporarily. The same mechanism could be used by non-profits like Internet Archive, where they could keep snapshots of this rich array of content in the library for posterity.

While this idea of links as resources came with the great properties of findability and archivability, it suffered from the perception of slowness, as each resource required you to load the entire Web page. After all, these were the early growth spurts of the Web. Compared to the desktop software of the day, Web-based applications were significantly inferior in terms of user experience.

Therefore, developers who were looking to improve Web-based apps needed to find a way to emulate the elements that made desktop software so smooth, bringing those elements to the Web. The solution was the scripting language (JavaScript) that was part of the Web browser; some of the responsibilities for rendering the user interface were shifted to this client-side programming language. So, instead of loading a new Web page resource with every single click, you loaded a Web page that contained this JavaScript program — which stayed on screen as a single page, then fetched the various resources in the background and updated a portion of the Web page dynamically, as soon as the request was fulfilled.

This led to the creation of single-page applications (SPAs) with frameworks like Backbone, Ember, Angular, (and now) React and Vue. These provided a way to emulate desktop applications within the Web browser runtime. The idea that these were resources you could fetch became more of a back-end concept. Instead of software returning a hypertext-linked Web page, it merely returned some data structure; initially in XML format and later as JSON, which stands for JavaScript Object Notation. Thanks to this method, data from the cloud could be loaded into these increasingly sophisticated, JavaScript-based applications.

With the advent of SPA, we saw the bifurcation of front-end development (which focuses on how the application looks and feels within the browser) and back-end development (which focuses on delivering data-only resources from the cloud). In a way, Software-as-a-Resource was still the predominant pattern for back-end engineers, whereas front-end engineers basically reverted back to Software-as-a-Product — where the app (in this case a JavaScript-based Web app) was created and downloaded to the browser once, then ran for a while, as it fetched new data or resources over time.

A good example of that transition is one of the most successful products Google ever launched, which is Gmail. Unlike Google Search, Gmail has a rich, long-running application that takes anywhere from 2 to 10 seconds to load; but, once loaded, it continues to refresh, bringing in new emails (aka resources) without reloading the entire page.

Now, Gmail is largely free. However, this paradigm of rich front-ends, which are connected to a universe of data, made way for the growth of the current dominant software distribution model: Software-as-a-Service or SaaS.

Software as a Service

The basic idea behind Software-as-a-Service is that users don’t need to install a software application on their computer. Instead, it relies on a lightweight runtime, such as the Web browser and the JavaScript capability inside the browser, to access a plethora of software services — without having to manage and maintain the infrastructure, such as the Web server’s database or storage. For the user, the value proposition of Software-as-a-Service is extremely high. It is very easy to get started and get value out of Software-as-a-Service.

Here are some of the qualities that make SaaS so compelling:

Salesforce.com’s “No Software” badge

1. No software installation: (Remember the “no software” marketing badge of Salesforce.com?) Users can start using a piece of software quickly and easily, just by providing an email address and setting a password. They can use the current version, but they will also automatically get access to new versions, without having to go through an upgrade process.
2. No custom development: Most SaaS products are preconfigured for a certain use case. Users can cover most of their needs by using the admin panel to upload a logo or configure some rules. Only users who need a much deeper connection between the software and their current systems have to install special plugins or do an integration via API. For most users, there is no lengthy period of set-up and customization.
3. No upfront payments: Software-as-a-Service adopts a rental model. Instead of licensing software via an upfront capital expenditure (CapEx), then paying a maintenance fee of 15–25% per year or buying an upgraded version at a slight discount when it is released a few years later, businesses can pay a steady monthly subscription fee as operating expenditure (OpEx).
4. Not limited to one OS platform: Most users use multiple operating systems in their work and home life. It is very likely that a user uses both Mac and Windows, iOS and Android, as well as many surfaces on the Web within a single day. In this multi-platform world, the idea of purchasing a product that runs only on a single platform seems antiquated. SaaS is delivered on top of the operating system. Once you have established a subscription, you can use any of the apps (that were created for each platform and that are offered by that particular service provider) as an onramp to the service. For example, as a Slack user, you can download the Slack app from the app store, so that you can connect to your Slack organization. But the app store doesn’t actually sell that Slack software as a product. This shifts the power of monetization to the SaaS platform and leaves the app store not much more than a curated catalog, where you can download the official version of the onramp.

SaaS brings benefits for service providers too. If you offer a useful service to a segment of customers, while managing churn through reasonable prices and steady streams of new features, you can create real stickiness; your customers will continue to pay the subscription, thus providing a steady stream of revenue. This is very different from the Software-as-a-Product approach, where each release had to be a hit in order for you to maintain your topline revenue. In that sense, SaaS can be compared to investing in real estate. Once you get a renter into a property, you can expect a reliable stream of income; you just have to offer a decent product at a decent price.

As a result of these dynamics, SaaS is eating the software that ate the world. It has become a money printing machine for many companies (such as Zoom, Salesforce, Slack, and Stripe, plus many more in vertical industries). Consequently, every possible software feature is now becoming a new SaaS startup. Each vertical market that has some differentiation based on unique needs (like doctors’ offices or barber shops) spawns a new SaaS competitor, who is trying to convert potential customers into a consistent revenue stream.

Not all Software-as-a-Service needs to be subscription-based, where the customer pays a monthly fee for productivity tools, hosted databases, or workflow systems. It can also be based on transaction fees that are typical for online marketplaces, where — in exchange for the use of the software — the software vendor takes a cut of the money you make through the app. Uber, Airbnb, and Instacart are good examples of such marketplaces. Essentially, they offer nothing more than a well-designed mobile app and an online dashboard; but in exchange for using that app and dashboard, they take a substantial cut of the revenue from the small businesses that rely on their platform.

Of course, there are some SaaS providers that are still supported by advertising, Gmail being a good example. Gmail is both advertiser-supported for consumers and subscription-based for businesses, who pay for G Suite via the user subscription model.

With recent IPOs from top SaaS companies like Dropbox, DocuSign, and Smartsheet, it looks like the subscription-based SaaS model is the only model that will be successful long-term. When it comes to advertising-supported software, it is basically impossible to beat Google and Facebook in their ability to cheaply target audiences on the Internet. You can either use Google’s and Facebook’s tools as your advertising engine and be satisfied with a small cut, while they take the majority of your value — or you find your own advertising niche and lose access to the broad market.

Even for marketplaces, it seems like the transaction fees generated by the buyers are just not enough to cover the cost of running a modern, software-driven organization. Therefore, big marketplaces are spending billions of dollars and they’re still not able to turn a profit using a simple, location-based demand-matching app.

At the same time, subscription-based services are able to reinvest their margins, thus growing to encompass more and more of the customers’ needs, becoming increasingly crucial for their customers’ lives or business operations.

Customer Lock-In

The proliferation of SaaS happens for a good reason: It is very easy to start using this type of software, while it is very hard to stop using it. It is difficult to get out, because the data you create with the software only exists within the boundaries of that particular piece of software.

Software-as-a-Product doesn’t have this problem. You can create a word processor document with Microsoft Word, and 10 years later, you will still be able to open that document on any computer that has Microsoft Word installed. With Software-as-a-Service, the lock-in comes from the fact that your data resides within the software; so, any artifacts you have created will only remain accessible if you keep an active subscription.

Although this may seem similar to the business model of self-storage, where people rent storage units to store their possessions for a certain amount of time, SaaS comes with an additional drawback. In contrast to a storage unit, from which you can remove your things at any time, you can’t move your SaaS data to another service. The data model and the user interface differ so greatly from one SaaS provider to another that it is virtually impossible to migrate your data to a competing service.

Feature Silos

There’s another problem specific to SaaS. Each software you subscribe to has its own set of features, which tend to overlap between different apps, without enabling you to merge them in any way. Your accounting data could be in one app, while your employee data is in another one. Your conversation with your employees is happening in one app, while your chat with your customers is somewhere else. You have to know exactly which app to use to reach which person, organization, and team.

Besides, you need to constantly reassess what logins, what access rights, and what sharing rules apply to the tens if not hundreds of SaaS apps that are in use within most organizations. While there are tools like Zapier and Integromat, which could be triggered when data is updated in one SaaS system and invoked in another, those data connectors become just another software service you have to subscribe to; in the best case, this works like a bandage for the data-and-feature silos.

Subscription Fatigue

As SaaS apps become more and more aggressive about getting people to sign up, the overall cost of subscription-based SaaS is now catching the attention of CFOs. How many subscriptions should one company need for an employee? Many organizations spend thousands of dollars per employee for subscription-based software.

As a result, SaaS providers are trying to increase the scope of their service, by cloning competitors’ features and claiming that you can eliminate your other services if you switch all your needs to theirs. For example, Microsoft Teams is going after Slack, incorporating Slack-like features into their own app that is included in the Office 365 subscription. Similarly, Google promotes Google Meet on every calendar entry within the Google calendar, even if a Zoom link is already included in that entry.

It is not clear how all this will play out — whether the financial incentives for reducing SaaS costs will drive consolidation — but either way, the cost of SaaS is going to be a major concern as more software shifts to that model.

Privacy

SaaS requires you to store your private data on someone else’s computer. That is probably well-known to everybody. When you upload something to the cloud, the privacy of that piece of information is only as good as the security practices of the vendor who is offering the service. Companies with stringent security requirements are starting to get concerned about sharing computing resources; in many cases, this is about sharing the same database between different customers of the same service.

Bigger SaaS providers have greater compliance and privacy guarantees. But when it comes to smaller SaaS products, you should just assume that a support person or a developer from the team can see everything you create in their system. As companies use more and more SaaS products, any private data is going to be in hundreds (if not thousands) of databases and storage units that would make an IT security professional cringe.

Half-Life of SaaS

Ultimately, SaaS companies are financial entities that can get acquired by other companies or go out of business altogether. When a company gets acquired, the acquiring company will often shut down the service and just provide a few weeks (months at most) for users to access and migrate their stuff, before the company deletes all the content and data, plus the code that renders the user experience, from its servers.

Even big companies like Google would retire perfectly good software, just because they don’t want to devote their limited and expensive engineering resources to maintaining something that won’t be a billion-dollar business.

For the smaller SaaS players, the founders and core teams may get tired of running and maintaining their software; they may sell to a new generation of SaaS investors, who will milk every dollar out of the customer base — not offering any new features, let alone keeping up with the competitors, until there is nothing left that motivates the customers to keep their subscriptions. Given the pace of evolution for software, the half-life of SaaS is less than five years; which means it is very unlikely that a piece of software will outlast a photo you took four iPhones ago.

Even though the SaaS era is currently at its peak, this particular delivery and business model for software is revealing its limitations. So, let’s look at where software could go after the SaaS era, by analyzing some of the new trends in the broader tech market.

Software as a Tool

A hammer is a tool. You can use a hammer to build a piece of furniture. You can borrow a hammer, buy a hammer, or rent a fancy one from The Home Depot. Let’s say you use it to build a chair. Once you are done, you can sit on that chair without the hammer being present or nearby. Now, if you want a plastic chair, you’ll need more sophisticated industrial equipment, such as a PVC injection molding machine that creates your chair from melting and molding plastics. However, the result is the same. Once the chair leaves the factory, it does not require the industrial equipment to function.

If you look at SaaS through that lens, you see how ridiculous this method of software distribution is. With SaaS, you never quite own the chair; you just sit on the chair inside a hotel room you rented inside someone else’s hotel.

Software can certainly act more like a hammer or a screwdriver. A good example is the camera app on your phone, which is a very sophisticated piece of software that allows you to take and edit beautiful pictures. But the artifacts (the photos) the app creates can be viewed independently of that particular camera app. If you took the photo on your iPhone, but your friend has an Android phone, you can still be reasonably sure that you will be able to send that photo over to the other phone, where your friend can open it. Your friend may not be able to access the coolest features that are part of your photo (e.g. the live photo feature from the latest iPhone may not be compatible with a very old Android phone), but the photo will still show up.

This level of compatibility and resilience is slowly disappearing from people’s experience with software, as we turn these tangible tools into ephemeral services that only work as long as you remain friends and keep paying your bills. Interestingly, though, there is nothing inherent in the construct of software that prevents software (and the artifacts it creates) from exhibiting the same type of compatibility and physicality you get from your camera app and photos.

There is a transitional class of SaaS called “no-code software”, which is about turning software into tools to make other software (or digital artifacts). Two shining examples of software that feels more like a tool are:

• Webflow, which allows you to make marketing websites with customized graphics and sophisticated navigation
• Canva, which allows you to create attractive graphics design that can be shared in various social networks with different size and shape requirements

These tools have a unique characteristic that makes them similar to the camera app: They generate artifacts that do not require their service in order to be distributed. For example, once you have made a Webflow website, you can export it to the standard formats of HTML/CSS and host it wherever you want. With Canva, once you have created your graphics design, you can download the images to your computer and then upload them to whichever image hosting service, chat room, or social media platform you need to spread your marketing message.

These tools are not free. Usually, you need to subscribe to a certain tier before the export options are turned on and you can actually migrate your data. That’s because the lure of the recurring revenue from SaaS is too great; Web services have to try to get you to host your creation exclusively on their platform.

In fact, many other no-code tools, such as Glide (a mobile app maker) and Airtable (a database design service), allow you to create your own mobile apps and spreadsheets; but they may require you to host your creation on their server. Even Webflow — even though it started out as a hosted website creation tool — is introducing more and more features that are only available if you also choose to host your completed site on their platform, taking advantage of their forms submission service, their e-commerce shopping cart service, and their integration service for other SaaS products. Even Adobe — which pioneered the creation of powerful photo editing and illustration tools — is moving away from the model where you bought their Software-as-a-Product, replacing it with a model that requires you to subscribe to their desktop software (“Adobe Creative Cloud”) and pay a recurring subscription fee. The “Adobe Creative Cloud” allows you to store all your artifacts on their cloud; you can send out Lightroom links to your photo sessions on the Adobe domain versus sending the JPEG in an email or a text message.

This temptation to turn tools into rent-generating services is making the lock-in — which is inherent in the architecture of Software-as-a-Service — much more universal. Even software providers who never used to play lock-in via recurring subscriptions are giving in to the walled-garden business model of SaaS, as a way to please venture capitalists or Wall Street.

Let’s talk about the qualities of Software-as-a-Tool, and how you can tell if software is a tool or a service.

Defining qualities of Software as a Tool

In the future, a lot of tools will be delivered through the Web and priced like SaaS. That’s why we need a precise set of criteria to distinguish software that can be classified as a tool. Software-as-a-Tool must be…

1. Untethered: You are free to move the things you create to a different host or computing environment. In other words, you don’t depend on one specific service from a particular vendor. You don’t need that vendor’s service in order to view or interact with the artifacts you have created with the software tools.
2. Substitutable: You can use different tools to create the same artifacts, due to the underlying compatibility of the file formats or data structures. The simplest example is a video editing tool. If you use two different video editing tools to create a video out of the same set of raw camera clips, your two videos will be basically the same. You can substitute one tool for another, as they can both fulfill the same job. Similarly (though this is a slightly more complicated example), you can use two different data analysis tools to process the same spreadsheet-like data structure and create a very similar chart.
3. Composable: You can mix and match tools to create your artifact. In order to build a house, you need more than just a hammer; you need different types of hammers, screw drivers, drills, ladders, etc. Similarly, most digital artifacts require multiple tools before they reach their final form. Even for data processing, people use various data science and data analysis tools to process the data set and finally arrive at an analysis.
4. Keepable: You own your artifacts and you can archive them safely forever. You won’t lose your creation just because the tool is discontinued or the software no longer gets updated. In other words: Software-as-a-Tool, like Software-as-a-Product, is something you can keep; while Software-as-a-Service is something you can’t keep (you can’t keep your Gmail data on your computer if you get banned from Google or your account is deleted). In that regard, Software-as-a-Tool is similar to Software-as-a-Product, because no third party can just take away your data.
5. Neutral: You can use the tools in your toolbox in any way you see fit. If you have a hammer, you can use it in various ways, from building things up to knocking things down. Digital tools exhibit the same type of neutrality; the tool, by itself, is fully neutral. But this neutrality disappears as you turn the tool into a service — e.g. to create content, distribute data, run a business, or connect with others. Suddenly, you are subjected to certain censorship rules or privacy laws, depending on the jurisdiction you are in. What are you using it for? Whom are you interacting with? What is your intent? This may differ from place to place, from country to country, but it is part of the social norm.

Most SaaS apps fail to fulfill the above criteria, meaning that we can’t consider them as the tools to build our digital future. They simply have a different value system with different priorities. In contrast to Software-as-a-Tool, SaaS apps are proud to be

1. Centralized: One place for all your stuff — very convenient. Which also means that you can’t migrate your data anywhere else.
2. Unique: They offer capabilities that you can’t find anywhere else. Which also means that there’s no substitute.
3. Comprehensive: Their feature sets cover a lot. Which also means there’s no mixing and matching with other apps.
4. Trusted: You trust them as your reliable partners. Which also means that you need to keep up that partnership (aka your active subscription) if you want to keep access to your data.
5. Compliant: They make sure they’re compliant with the law. Which also means their services are limited. There are certain things they can’t do for you, because a service is never as neutral as a tool.

The consequence of those qualities is that users will always remain passive consumers of the software. They can’t be turned from passive consumers of these amazing services into active builders of their own digital spaces.

The US went through a do-it-yourself (DIY) movement when The Home Depot and other home improvement stores — each with a warehouse full of tools, parts, and materials — became a fixture in most suburban towns. People learned that many of the things they used to pay a professional for (to do the work for them as a service) turned out to be things they could do themselves; all they needed was a little bit of education and experimentation. This knowledge was incredibly empowering; not just because they were suddenly holding fancy power tools like drills in their hands, but because the waiting time disappeared. They no longer needed to wait for someone to do something for them; they were now able to do it themselves, so they replaced the broken mirror in their bathroom in one weekend on their own.

This process also demystified the thought of what it takes to build something from scratch. People started buying more tools, setting up workshops in their garages, and building whole swing sets themselves. Furthermore, it commodified the tools that now have a much larger customer base; so that, instead of selling tens of thousands of table saws to professional carpenters, manufacturers can sell millions of table saws to hobbyists, thereby driving down the cost of home improvement tools.

Look at the current software market. Behind the modern brands of SaaS companies are legions of software developers, spewing jargons and technical terms, as they talk about JavaScript, the cloud, and GitHub. That intimidates most regular people, including business owners who think, “I can’t do this software thing on my own; they are so much smarter than me.” But if we hand over the software in the form of tools that people can experiment with, they can start building things on their own. They will realize how this composable and untethered software enables them to create artifacts themselves — artifacts that outlast the feature list of certain SaaS companies.

Many of the no-code tools that already exist are beginning to address this desire of regular people, who want to construct software systems that will solve their problems without going through a development team that acts as an intermediary. However, most of these tools exhibit the negative characteristics that are typical for SaaS, as they lock their no-code builders into their platforms, unable to escape that platform’s business model. Fact is, if you are a house guest in someone else’s house, you play by their rules. And when you need to leave, e.g. because the business you created using their tools has grown, it turns out to be impossible. If you leave their platform, you can’t take your creation with you. Instead, you will find yourself needing to build your whole system again from scratch, using the regular development tools that developers use every day — which are untethered, composable, substitutable, keepable, and neutral.

How developers use tools

A lot of the qualities we need to define Software-as-a-Tool already exist in the developer tools market. Unfortunately, in order to use those developer tools, you need to know how to read and write code; you need to understand the nitty-gritty aspects, knowing how the software works behind the scenes. But behind all those intimidating command lines and technical jargons lies a very practical need for simple yet powerful tools — tools that can be used and reused to create artifacts (in this case software) quickly and reliably.

Contrary to the movies’ portrayals of genius hackers, programmers do not sit at their desks and invent new, world-changing concepts every day. By and large, programmers do what home builders do: They have the right tools in their toolbelt and they have the skill sets to glue things together; but most importantly, they know the catalog of parts and tools in The Home Depot of software.

These supply stores are called “package registries”. Every programming language has a different package registry, which collects useful bundles of reusable code. Developers can pull that code from the registry and incorporate it into their programs, so that they don’t have to write it from scratch.

For example, say a developer is building an HR system and needs a calendar widget, which allows the user to enter a birth date or pick it from a month/year control, which detects whether the birth date is valid or invalid, and which supports the different types of international date formats that would be expected in different geographic regions. It makes no sense for that developer to write an international calendar from scratch, given the time pressure he is under to deliver a working version of the HR software. Instead, a vast majority of developers will choose a mature, elegant, feature-rich calendar widget from these package registries and hook it up with the rest of the screens they are building, to get the job done as efficiently as possible.

In the past, those widgets were either part of the operating system, shipped with the software development kit (SDK) of the OS platform, such as Windows, Mac, or iOS; or they were part of commercially supported widget libraries, where developers could purchase them, which saved them time and therefore saved their company some money.

Since open source became the primary way for developers to share code with each other, most of these off-the-shelf modules have actually been shared as open-source code, packaged and distributed through package registries. The source code of these modules always has to be available; this way, in case there is a small error or bug in the calendar library, a developer can inspect the underlying code, make fixes for the main project, and then submit the changes back to the original author of the calendar widget as a contribution. The sharing of code and patches between developers, especially in these libraries and modules, has become a big part of the community-building and social-status-building process, enabling developers to raise their status within the open-source community.

Some developers may even go beyond submitting patches. They share elements of their own work as open-source packages. A developer who is working on HR software, for example, could build a great method for capturing people’s full names in all possible variations (name order, accents, suffixes, prefixes, etc.). He can start an open-source project for this library, title it “nameo”, and become known as a contributor within the open-source ecosystem. Another developer, who is working on a travel site project, declares a bunch of dependencies with different modules — which were contributed by thousands of developers and bundled together into one or more chunks. They are then uploaded to the Web and downloaded from your browser the first time you visit this travel site, which uses both the “nameo” module and the calendar unit among hundreds of other packages.

What the users see when they are working with this e-commerce software — whether it is monetized via advertising, subscriptions, or transaction fees — is actually an amalgamation of thousands of open-source packages, which are responsible for up to 90% of the lines of code that are running to deliver the end user experience. As little as 10% of the code is written by the development team of this site, capturing the unique requirements, architecture needs, branding, and look and feel for this particular application.

In the JavaScript developer ecosystem, which is used to create most user interfaces for SaaS apps, a lot of these modules are stored in a package registry called npm. That package registry was recently acquired by GitHub — a social coding community, where developers can share not only the open-source code they write, but also the proprietary code they create for their companies. npm is a largely free service, which can deliver gigabytes worth of third-party packages every time a developer starts working on a project that already incorporates hundreds, if not thousands of dependencies.

npm has a sophisticated versioning scheme, allowing developers to declare which version or range of versions of the package in the registry is needed or compatible with the code they are writing. Dependencies are both a blessing and a curse. They save you time, as you can build something using software that already exists; but they’re also responsible for headaches, when you have to manage the upgrade of packages, so as to take advantage of new features or bug fixes, while trying not to break the app you are currently building. If you have ever tried to update a version of a desktop app and weren’t able to open a file, you know how frustrating this can be.

Of course, it is still a net gain for developers to have access to these ever-growing collections of parts and tools, compared to building everything themselves. But when we look at the way developers manage the reuse of these prebuilt tools and packages, we see a glimpse of what a world built on top of Software-as-a-Tool will look like. We just need to extend the paradigm of open-source code sharing, registries of packages, and sensible dependency management between all the parts.

The goal is to give end users access to these powerful tools — like a calendar, a name field, an audio player, an application form, a survey form, or a shopping cart. Users should be able to pick these tools from a catalog and assemble software themselves — software that exhibits all the characteristics of Software-as-a-Tool, which distinguish it from its Software-as-a-Service counterpart.

This way, we can do for software building what the DIY movement did for home improvement.

This is not to say that professional engineers won’t be needed; they play a crucial role in creating the high-leverage components that populate the catalog. So, the key is to figure out how to compensate all the people who have contributed various parts to the end result — your website — when your business, which is based on your website software, becomes fabulously successful.

In the next section, we will look at the different business model options to compensate the tool makers, builders, and service providers who keep the software running, by rewarding them for their contributions.

Business model options

Bundling–Unbundling

Software-as-a-Tool, in a way, is an unbundling of all the features that make up multiple Software-as-a-Service products. Once unbundled in the technical sense, we can rebundle them in new and interesting ways.

One example of monetizing Software-as-a-Tool is charging a subscription fee for unlimited access to every tool in a catalog. This is similar to Spotify’s monetization of music; for one monthly subscription, you get access to the entire catalog of recorded music from around the world. On top of this, you could add multiple tiers or bundles, including premium add-ons; which is similar to the different plans and packages for cable TV that cable companies traditionally offer.

But you don’t have to charge upfront. You could also meter how often the tools are used. Then, you charge the operator — a hosting company (if the software is hosted by a third party) or the business (if they choose to host it themselves) — who will pay for the tools based on that metered usage. Cloud providers like Amazon Web Services bill for their services in a similar manner; but obviously, this will be harder to do with tools that are being used in all kinds of different environments, where tracking may not be possible or desirable.

This combination of techniques offers many possible ways to price the tools, so that the cost fits both the budget and the expectation of the customers. Here are a few examples:

1. Free to use: The tool is open-sourced, which is the norm in the developer community. The author only wants to gain some popularity and recognition, but doesn’t expect any monetary reward in return.
2. Buy this tool for $2.99: Users purchase the tool like a product, acquiring a license for themselves (one person only) via their email address or business domain. Once they have licensed it, they can use it for all their needs, while every other person needs to buy his/her own license.
3. Pay $0.10 per use: For tools that aren’t used regularly (e.g. generating a QR code with some special features), users can pay separately each time they use it. If they use it more often, they may get a special discount.
4. Subscribe for $5 a month or $50 a year: This is not all that different from Software-as-a-Service from the business perspective; except that, if users stop subscribing, they still have read access to all their data. E.g. an audio card would continue to let them play back the audio, while the editing tool that comes with it may no longer work.
5. Pay $75 a month for the gold tier: A company may pay a subscription fee per user per month for a gold-tier bundle. An HR tool could be included in that tier, without collecting any additional payments, even though the provider of this tool may not be the same corporate entity as the organization offering the tiered plan. This approach requires a particular payment and accounting mechanism.
6. Buy this tutorial with examples for $199: A particular tool (e.g. an app for creating marketing landing pages) is free to use. But users want to learn how to use it effectively, while getting some templates and samples as starting points. There is a big market for informational products on the Internet, which have some educational components and some digital-product components. Authors can sell those tutorials instead of selling the software itself; this way, they make enough money to maintain the software without having to offer it as SaaS.
7. Buy premium themes and templates: There is a large market for themes and templates that are used by the WordPress community. A lot of those templates may be assembled from the packages in the catalog. They are basically bundles of pre-integrated tools, e.g. specific for the real-estate industry.
8. Get this tool integrated with your back-end for $500: There is an opportunity for developers to offer productized services, similarly to Fiverr, where freelancers offer their services and e.g. draw you a logo for $20. A developer could sell the productized service to adapt a certain package to a user’s unique backend; which would cost much less than building an entire application from scratch. When users need a certain extension or integration, they can commission one of these packages via quote (possibly a fixed-price quote) and add the module to their environment. If they find this integration, which they commissioned and paid for, extremely useful, they may even offer it to other users through the catalog.
9. View for free, pay to create something new: This is similar to Adobe’s method of splitting the creator and the reader for PDFs into two separate products. Adobe Acrobat Reader is given away as a free download, but the Creative Cloud, which is used to create and edit PDF files and forms (among many other things), is a paid service.

These types of business models will need much more distributed accounting and payment dispersion systems than the simple SaaS math done by Silicon’s Valley’s startup bank accounts. Many of these models require payment distribution across multiple parties. In order to make this work, some sort of digital money (aka an accounting ledger that can be manipulated in a purely digital form) will be a prerequisite. PayPal was one of the earliest forms of digital money. But in the future, blockchain and cryptocurrency are going to play an important role in capturing, dispersing, and converting different forms of payments, which allow contributors to get rewarded for making their software available as a tool.

Build vs Buy

Customers should be able to buy or license 90% of what they need to build their digital experiences from the catalog, using one of the business models suggested above. The remaining 10% will still need to be built as software, either through coding or through no-code configurations.

Organizations that adopt Software-as-a-Tool can hire staff or consultants to customize, extend, or integrate the off-the-shelf software with their existing business practices. They can keep these customizations as private as proprietary code and run the whole combined software stack in their own cloud account (whether that’s on Amazon, Google, or Microsoft Azure), so as to retain their competitive advantage and proprietary trade secrets.

Alternatively, organizations can decide to share their work with the world, publish their plugins to GitHub, and then push them to a package registry like npm. They could even put a price tag on those modules. This way, people who want a one-click install as part of their no-code experience can instantly incorporate those functionalities into their running environment as a dependency.

For personal use, you could add the missing features to your software toolbox by hiring someone to write certain scripts for you and deliver them to you as links, so that you can just add them into your running environment. In other words: The build portion of Software-as-a-Tool incorporates the flexibility to extend Software-as-a-Quote, without the limitations of Software-as-a-Product and Software-as-a-Service.

Content & Code

The ultimate goal of Software-as-a-Tool is that the tool is distributed with (but behind) the content. For example, when you encounter a video (which is content), the video player or video editor can be loaded if you have that tool in your toolbox. The software disappears behind the content, data, or asset that you are exchanging. Behind the scenes, the runtime is instantiating copies of those modules in your browser, while you encounter different types of content. Currently, this type of streaming instantiation only happens within the boundaries of each browser tab; but if there were a more modular delivery network, you could deliver the module within a content management system app whenever you encounter a new form of content, such as a 3D model play. However, that module would not be coming from YouTube or some sort of hosted service; it would be delivered from a curated software catalog without any terms of service (but perhaps with a licensing agreement, like an open-source license) attached. Remember, it is just a hammer.

Safety & Moderation

The Web platform — especially the Web browser — has a great track record when it comes to safety and reliability. It is very unlikely for something malicious to happen to you if you’re just browsing a Web page. This is the result of extensive engineering efforts to provide sandboxes for JavaScript code, ensuring that they cannot access data they are not supposed to access.

Still, if we want software to be distributed more easily and installed more automatically in various hosting environments, there has to be some form of moderation and curation for this shared module catalog; items that are included in the catalog have to be considered safe. Apple employs human reviewers for their proprietary app store. They interpret the app store’s policy and make more or less arbitrary decisions about whether your app (or the updated version of your app) can be pushed to the app store or not. That process is obviously uneven, because the result depends on the reviewer. And a recent incident shows how unfair it can be, e.g. when Apple’s financial interests conflict with the app developer’s interests (because Apple wants to collect 30% of the SaaS subscription revenue for a paid email product called “Hey”, but the developer refuses to pay that commission).

In the open-source world, the community relies on a different method to ensure that things are safe. They only trust software based on source code that is made available for public viewing. This way, other developers can audit your software, inspecting its internal logic, in case it is suspected of doing something shady.

Enterprises or bigger businesses want even more guarantees than just the idea of developers keeping people honest. They are willing to buy third-party validation, testing, support, and warranties as optional services; and they only trust software catalogs that have been certified by such a trusted party. This has happened in various open-source communities (e.g. Red Hat or Drupal), where there are many user-contributed modules, and a bigger company distributed pre-validated modules as part of a premium support package.

Some developers want to distribute their software without making the source code available; or they want to submit software to high-risk categories like cryptography or blockchain. In that case, the model of requiring a security deposit (also known as “staking”) creates a something-at-stake situation, where a penalty can be deducted from their deposit if a bad event occurs.

In general, Software-as-a-Tool will benefit from multiple methods of curation and ongoing feedback. This could include an alert list feature, where software that has been identified as malicious can be blocked across a global network of service providers. In order for this approach to work, it would have to be a safety requirement for all service providers (who run these tools) to subscribe to this alert feed, act upon it, and remove malicious apps from use immediately. The combination of these techniques will likely result in the same level of safety people depend on when they use app stores, while facilitating a much more open marketplace of ideas and monetization.

Conclusion

Software remains the most flexible artifact of human creativity, as it is only limited by imagination and has no inherent forms or limits. Just as software can do anything, it can also be distributed in many ways. In this article, we have discussed how software has evolved from a product into a quote into a resource into a service and now into a shareable tool.

It is possible to turn the qualities of Software-as-a-Tool, which already exist in the open-source software ecosystem, into user-accessible parts that allow users to build up a healthier, less extractive software ecosystem. But tools are only part of the solution.

We still need product designers who know how to combine these tools to build products that solve a set of problems beautifully. We still need service providers who are willing to host these tool-based products, providing reliable hosting services at a fair price, which can be accessed 24/7 from anywhere in the world. The Web pages containing all the data, content, and assets, which are hosted by these service providers, need to be viewable and hyperlinked as Web resources. This way, we can break the silos of these incompatible SaaS apps and return to the more open, interconnected vision of the World Wide Web that was initially intended, before the tech giants turned the Web into walled gardens.

We want software to be able to be extended in any way that can be described in words, by leveraging the custom-software industry to expand this catalog of possibilities with client-facing collaboration and problem solving. The software market always reconfigures itself around the limitations and the possibilities afforded to it in a particular phase of the technology world. If a CD-ROM can only store 650 MB of material, you know that some developers will find a way to use every single corner of that disk they deliver to the customer.

Now that the Internet connects every person and every computing device, there are no limits to what we can deliver. When we look back at the silos of SaaS in 20 years, we will think of SaaS as limiting and ridiculous, just like the boxes of software on the shelves of the computer stores.

The paradigm of streaming versus downloads will not only transform the content industry with Netflix, YouTube, and Spotify; it will also fundamentally change people’s relationship with the software that is eating the world. Once everything is software, you shouldn’t see it anymore. If software is everywhere, just like the air that surrounds us, it should just disappear from view. It should become a substrate of the digital life it permeates.

Learn More

The Evolution of Software Distribution (1995 to 2025) — Cardstack Tech Talk

• Cardstack Vision Paper: On Decentralization of User Experiences and Fair Distribution of Rewards in Future Software Markets
• Cardstack.com

To get all our latest updates, star Cardstack on GitHub and join our Discord channel or our Telegram group and announcement channel.