What killed the shrink-wrapped market was first piracy and secondly the way people use their computers change. Then add on the easy sharing that e.g. Google docs enables and it's all over but the shouting.
The SAAS model also has the benefit of aligning value delivery with outlays temporally. No more wait a year before shipping: instead get quick iteration with an ongoing revenue stream. You can recover from missteps in a way that the old model could not.
Not sure how to respond to that. Emacs is around, the latter two I believe not, but approximately nobody is using them anyway. And I say that as someone who lives in Emacs.
> OS vendors still make money despite Linux and FreeBSD.
Apple makes money on hardware. Microsoft makes money on cloud, and has been desperately trying to turn Windows into a subscription service for a while now. They even non-humorously said exactly this in some message in (IIRC) installer or update screen - I remember Windows 10 telling me "Windows is a service" as if that was a good thing.
> The GIMP didn't kill Adobe.
No, but again, GIMP and Krita are used by approximately no one, meanwhile Adobe switched to a quite abusive subscription model.
> And if you want to sell proprietary libraries your market is going to be limited because OSs will distribute them and it will be hard to keep up when customers are fixing their own problems.
I don't see how. Think about the 100 (or 10 000, if you're doing webdev) dependencies your product uses. Most of those could be a licensed product, creating a cottage industry of small vendors making a living from developing specialized libraries. This thing is real in some areas, e.g. industrial software, where there are e.g. protocols that are too complex and boring for Open Source community to care about supporting in full. But it's something impossible in general, because popularity of open source simply prevents this kind of market from forming.
Now, to be clear: I don't have a strong opinion on whether this is good or bad. Still trying to fully understand that one. But what I know for sure is that open source is a huge disruption to how the market would've worked otherwise.
> What killed the shrink-wrapped market was first piracy
I'm not convinced about that. Maybe video games had a problem, but money in software in general was in B2B, not B2C, and there the piracy was effectively mitigated by the legal system. In fact, both Microsoft and Adobe used piracy as opportunity because of that - kids would grow up using pirated copies of professional software, and then as adults, their companies and their employers would have to buy the properly licensed versions of that same software, because that's the only thing anyone has experience in using.
> The SAAS model also has the benefit of aligning value delivery with outlays temporally. No more wait a year before shipping: instead get quick iteration with an ongoing revenue stream. You can recover from missteps in a way that the old model could not.
SaaS has some benefits, but they tend to be single-sided, unless the customer and the vendor are comparable in power, which usually isn't the case. So while e.g. IBM or Microsoft can force Google or Adobe to behave, my small business will be taken advantage of by large SaaS vendors.
Computers always allowed you to copy code for free and any new concept that took six months to be made up, can be duplicated for free in one second.
The real problem is that you have to ship code that can be disassembled and read by another human being, to sell software. This fact annihlates any incentive and control an author-of-software has over their conceptual labor.
What we need is a method to sell a binary (and source-code) that are completely free of human-perceivable information AND authorized against a purchase server. Identify the code author or not, both are fine, what matters is the conceptual labor is protected.
That's it. We do that and it becomes viable to do hard mental work for a long time, and take risks on bold moves. Make the concept work and sell the baked end result without giving away the recipe.
Every other industry keeps the means of production to themselves.
But for some awful reason, programmers are expected/required to ship the means of production, the understanding of the code and the concepts of the code AND be ready to answer anything, in a relationship with the purchaser.
The balance of effort between software developers and the benefit everyone else gets from them, is completely messed up.
That sounds impossible in principle, not without taking away ownership of the machine from the user. I guess TPM + homomorphic encryption might allow this one day, but that doesn't feel like a win for society.
> But for some awful reason, programmers are expected/required to ship the means of production
Pedantic, perhaps, but I wouldn't classify code as "means of production". Dev tools and supporting tooling, maybe, which no one is required to ship.
I sort of agree with you're saying overall - you're pointing out the fundamental issue, open source is just something enabled by it. I focused on open source because, arguably, this reality of "messed up balance" was still manageable through the legal system, and it's the FLOSS becoming a cultural phenomenon in the industry that broke this.
[0] https://en.wikipedia.org/wiki/Phil_Zimmermann#Arms_Export_Co...
Generally it does not:
Microsoft Windows EULA states:
"Disclaimer. Neither Microsoft, nor the device manufacturer or installer, gives any other express warranties, guarantees, or conditions. Microsoft and the device manufacturer and installer exclude all implied warranties and conditions, including those of merchantability, fitness for a particular purpose, and non-infringement. If your local law does not allow the exclusion of implied warranties, then any implied warranties, guarantees, or conditions last only during the term of the limited warranty and are limited as much as your local law allows. If your local law requires a longer limited warranty term, despite this agreement, then that longer term will apply, but you can recover only the remedies this agreement allows."
Source: https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/U...
Oracle EULA states:
"Disclaimer of Warranties; Limitation of Liability THE PROGRAMS ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. ORACLE FURTHER DISCLAIMS ALL WARRANTIES, EXPRESS AND IMPLIED, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT."
Source: https://www.oracle.com/downloads/licenses/standard-license.h...
And that's a real damn shame, too. If only we had actual Engineering certifications for software engineers.
Things would be a lot more expensive... but perhaps they'd be a lot more consumer-friendly too.
An ethics course is no panacea. But what I learned in ethics has been far more useful in my career than a lot of my hard CS subjects.
See Canada: Software Engineers are called Software Developers there, problem solved.
(Now, there might be an argument you could make that, if software engineers had actual certifications, they would have the leverage to push back against Microsoft management and say "no, we're not going to ship that". But I'm pretty sure that wouldn't work, at least not at this stage of the game. Microsoft would just find coders in India or the Philippines or somewhere to implement it where there are no such professional regulations. No, when a company the size of Microsoft does something like that, the problem is not with the individual contributors.)
I mean, you don’t sign a 20 page contract when you visit a restaurant saying you agree not to sue them if you get food poisoning. Or sign something saying you take responsibility if you die in a plane crash, or from a shoddy building collapsing on your head. Companies in all other areas of society are held responsible for foreseeable harm caused by the products they sell. EULAs make a mockery of that, and the law should void or ban them.
Software also suffers of untold expectations. Companies regularly spend as much time writing specs as developing the real software, and yet, imprecision still dominates the implementation.
In fact, in the US, if you get a licensed engineer to do an inspection or design job, they will also often include a list of disclaimers to avoid liability. You often have to negotiate the lack of said liability waiver in advance for a higher fee. Note, liability waivers don't protect from negilence, just all other scenarios.
That's a deep rabbit hole that leads to the Underdark (https://en.wikipedia.org/wiki/Underdark) of Enterprise Legal Agreements.
Only high-level legal wizards and magisters can go there and expect to understand anything and keep their sanity.
Not a lawyer, but I expect it comes down to "if you follow our guidelines and pay us enough we can make the following guarantees, but there are certain things that we simply do not cover."
This is exactly what a warranty is though.
Yes, but it is not for consumers. It is for big businesses that pay millions and have specific expectations. The more you are willing to pay to more you can get within specific limits.
Your original statement, "If you pay for software it generally comes with some warranty and guarantee of fitness for purpose." does not hold for consumers and only partially holds for enterprise customers.
It might be better stated: "If your business / entity / government has specific needs (e.g. compliance with legal or medical regulations, industry certifications, ISO requirements, auditing, etc.), has a large sack of money to pay, and a team of lawyers, then there are some software publishers who will sign contracts to guarantee you certain qualities about the software you license with them and perhaps some level of support of that software."
---
Limited Remedy. If Microsoft, or the device manufacturer or installer, breaches its limited warranty, it will, at its election, either: (i) repair or replace the software at no charge, or (ii) accept return of the software (or at its election the device on which the software was preinstalled) for a refund of the amount paid, if any.
---
Unless it's some sort of bespoke software with a detailed contract (the details of which aren't available), I don't believe that's true.
Every single software license (as well as websites and other services) I've ever read (over the past 30 years or so) has had some similar disclaimer.
Would you provide an example that doesn't follow that pattern?
What needs to be done in commercial software, as is done in all other industries and in existing safety-critical software deployments, is segregating use cases by criticality and requiring deployments reach and guarantee the necessary quality level for that criticality class. It is the job and liability of the deployer to guarantee the requirements are met. They may push these requirements down to their suppliers, but it is the deployer that is ultimately responsible.
This is why Home Depot is not required to only sell aircraft-grade rivets. It is the airplane manufacturer’s job to source adequate components, not the job of all component suppliers to guarantee their components are fit for all possible purposes.
Under this model you can release any software you want. It is the manufacturer using the software that bears the burden of proving it is adequate. Or, if the software maker want to voluntarily take on extra burden, the software maker can verify and certify that the product is adequate for whatever purpose they wish to support.
Quality where it is necessary, and flexibility where it is not.
Conversely, we don't want to lose FOSS because single developers can't cope with the legal risks. Maybe there's opportunity for incentivizing cheap security certification of FOSS, or a CISA-approved subset of FOSS that is guaranteed to follow strict security practices.