Posted by lhoff 10/27/2024
>> (By the way, all new software without accompanying support & guidance is doomed to fail. And if that software comes from a dominant player, you’ll just have to deal with that by the way.)
There's a temptation to conflate the software license with the software business. This is natural, but places software as the primary value in the chain.
From a business perspective the software though is a cheap part of the chain. And the least interesting part.
I don't pick say accounting software based on price. Or access to the source code. I base it on effectiveness. And a big part of that effectiveness is that staff can run it. And when it all goes wrong there's someone to call. I'm buying a -relationship-, not software.
Thats why RedHat is a business. They're not selling Linux, they're selling the reliability, longevity, services, support etc.
In truth the license doesn't matter. My accounting software might be open or closed. My supplier doesn't sell me based on the license. They sell me by convincing me that everything just works, and when it doesn't they'll be there to fix it.
>In truth the license doesn't matter.
It's funny to bring that up in the context of Red Hat who have started to circumvent the GPL by terminating their relationship with anyone who tries to actually make use of the rights granted by it. "The license doesn't matter" because they've found a loophole in it, but it clearly does matter in that they had to do so in the first place and weren't able to adhere to its spirit due to business concerns.
[1]: https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis...
[2]: https://opencoreventures.com/blog/2023-08-redhat-gets-around...
This is only because true most of the time businesses use a lot of publicly funded work without paying for it. If software development were entirely private, I'm sure businesses would find excuses that actually no it has to cost 100x what it would cost otherwise.
Everything you say about maintainability and stability is true. But writing software that can be operated as a service in the first place is substantially harder. It's just not as easy for a company to capture.
and they'd tell you to pay up 10x, or lose this stability in the future;
If it was an open source software, you will have the option to go to a competing vendor.
You could say that Canonical and IBM RedHat compete on offering Linux support, but the reality is that it's not that much harder to switch from RHEL to Ubuntu than switching to any other OS, so I don't think this counts.
IBM RedHat is the steward of RHEL, and Canonical is of Ubuntu, so if you want support from them there are no real other options, but they do work with multiple different ISVs.
If you want to stay 'independent' and have the most leverage you can take a linux which is not from a bigco, such as Debian.
I'm really worried about cloud-lock-in for bigger companies. My previous company switched large amounts of product to AWS, when I asked about how this was feasible after doing back-of-the-envelope calculations they said: well you should not consider list price, nobody is paying list price, we get discounts.
This reminded me of an ISP I worked for in 2006 that invested in large amounts of Solaris machines because they got big discounts instead of going for the much more obvious Linux route. Then after two years or so the new (Oracle at that time?? I'm not sure) sales rep paid a visit and they said, when they were not able to sell MORE new servers: OK screw the discounts, from now you're paying list price. So that got them stuck in a real bad place. I'm afraid the same might happen to companies who move to cloud providers as well.
And then I've not even touched on issues such as privacy, security, business continuity, and losing the skill to actually run your own hardware
i see a trend in recent years in losing the skill for making proper software too - Something that works and is usable and is not about changing colors and pixels and protocols everyday for the sake of it. Maybe the opposite trend of the everybody-can-program since 1995? Or maybe not - not sure how ML-generated stuff will impact all this.
btw there was ~2021 talk/article by same guy about how outsourcing-everything leads to total deskilling:
[1]:https://www.suse.com/c/embrace-linux-diversity-simplified-mu...
You miss the point. Enterprises don't go looking for another vendor. Vendors come to them with a sales offering.
If I'm running SQL Server the I pretty much know where I stand with Microsoft, and there are endless MS approved support people.
With PostgreSQL some vendor has to come to me and convince me to switch. PostgreSQL is really well supported, and it's at least an option. 99% of Open Source though has 1 or 0 support entities, and 0 sales people.
Sure, with PostgreSQL I can do my own research. I might even have skills to do it myself. But now I have to explain my choices all the way up the ladder.
Am I going to use an OSS accounting system with no sales people? With no support people? Or am I gonna pay $99 a year or whatever for QuickBooks?
I totally agree with this. And not just businesses, individuals too.
On the flip side lot of open source devs are going to get 100x more productive in the Exploit part than the avg coder monkey at large corp.
Nothing is obvious and predictable about where that story goes in an ever growing ever changing system.
Large corps will keep funding whoever gets the job done. While AI might replace lot of Large Corps activity which is basically on the Exploit side of the Tradeoff.
It’s hard but I still think that’s the way to support OSS
The rise of the Internet and the dot-com boom happened largely without OSS, on proprietary UNIXes, proprietary web server engines, and proprietary database engines.
FAANG and other high tech businesses can easily afford very expensive servers and datacenters to house them thanks to the very very fat profit margins. They can also easily afford the cost of an OS license and other software tools.
I remember visiting early Hotmail and their sharded “capital unit” was a great big Sun storage server and a bunch of Intel desktop towers running BSD. The latter was considered rather wild at the time.
Last I checked, some eBay URLs still had “ebayISAPI.dll” in them, which is a remnant of that period.
> In truth the license doesn't matter.
Come on. What matters is the way the business extracts value from you, and the license is part of that. Especially when the software you produce is so great that nobody needs to be called, because it just works.
Still, the licence doesn't matter - while probably being a bit of an overstatement - is somewhat true. If my enterprise relies on an Adobe service, it's primarily about my relationship with them, not the product license.
... But of course, product price and therefore revenue will decline if competitors can sell my product too or customers can download and use it for free.
That is forgetting why your enterprise relies on an Adobe service. It is because nobody else has software that does their job as well as Adobe does.
This discussion is non-sensical to me. Of course the license matters.
So you would pick a software costing 1 million over a software that is 90% as effective but costs 1 thousand?
If it fits your budget, and a commercial product has a good sales team (vs a cheaper opensource one with zero marketing), the commercial product is gonna get chosen even if it costs infinitely more. That's basically IBM and Oracle's play book.
> what sells in enterprise is marketing and a good sales team, not "effectiveness"
I work for a SaaS company. Our marketing and product teams work hard to convince potential customers that our software fulfills their needs at a reasonable cost.
When we buy services and software we don't look at any of the marketing materials, there are very trough analysis of costs/benefits being made, dollars and even cents are counted. Every cost that can be cut while we can still deliver something to our customers will be cut.
Outside of tech, that's not how it works. They don't have in-house developers. They don't read HN. When they need a database, they ring up a large vendor and spend hundred of thousands a year for Oracle, when a PostgreSQL container would do just fine. They often don't even care they could pay zero, simply because PostgreSQL doesn't come with a phone number to call when the DB crashes.
Paying someone else to solve your problems can also carry huge risks of all sorts. Sometimes investing 1000 dollars into a risk-free solution is better than 5 dollars a month with gigantic strings attached.
The license matters indirectly: if it's open source, you know that as a fall-back other suppliers might be able to step up and take over, if your original guys fail or get too insufferable.
Firstly, of course, most customers don't have any programming skills at all, so the point is moot. But let's limit ourselves to customers that do have IT departments.
It's worth noting that IT departments are already busy. Deploying resources because you found a bug in PostgreSQL is unlikely.
But ok, you found a bug. And we happen to have a highly paid C programmer on staff. Let's ask him to take a look.
He's not familiar with PostgreSQL architecture- do it'll take a few days to download the source, make a build, hope the build is close to our version, and deploy to production. (This has already cost the business more than a enterprise support contract from Postgres but whatever...)
He then spends a month working through various subsystems to determine the exact flow that leads to your bug. (I'm gonna ignore all the cases where the "bug" isn't a bug.) He makes a tweak, merges it into the current build, and deploys.
He even submits the PR which may or may not be accepted. Until it is he's regularly pulled from his task to update the PostgreSQL source and rebuild.
Everyone else plagues him either PostgreSQL questions twice a week now. His manager gives him a 'poor' rating at the next review because the thing he was actually hired to do is not getting done.
Unless the company is selling to other PostgreSQL developers, there's no "free publicity". That's not how publicity works.
So yes, your scenario is possible, but its simply not how things happen. You complain to the IT department - they add PostgreSQL enterprise support to the next budget. They're not looking to take on extra load unnecessarily.
Yes, the major contributers to big OSS projects are tech companies contributing full time programmers. And that's a good thing. But customers do not have the time or resources (or inclination) to go down this road.
Frankly, it's too hard (in most cases) to just build the software, much less understand the code to make changes.
If we're worried about the supplier now then we don't bu from them. If they suddenly change down the road (and most established ones don't) then the fallback is either "we don't need support anymore" or (more likely) we start looking for another system.
I've been on the other side of this. We sell a product into an established mature domain. We're the "newbie" on the block. Most of the sales we get in this space are from customers who are unhappy with their supplier. We offer better sales and service, and obviously a smooth transition from their existing data (which we import.)
Neither product is OSS - but even if it was that would be irrelevant to the user. (It would however have made our integration code a lot easier to write, so there is that...) A lot of the users we convert have "bought" their software. It's costing them nothing to use it. But they switch to us anyway (we have a subscription model) because our model can afford to fund full time support staff, whereas the sales model cannot.
So, I think this "choose another servicer" is more of a theoretical than practical feature for most OSS systems. Obviously there's really good support for the really big projects, but basically nothing from 99% of them...
This sounds just like a general argument against prenups and specifying any kind of contract penalties?
In any case: one way a supplier can make me less worried about them now is by open sourcing.
I mostly agree with most of your points.
RedHat providing OSS licensed software is _less_ risk than RedHat providing proprietary closed source operating system.
It only doesn't matter if you don't care at all about software supply chain risks.
This is not a sane position in 2024 to hold.
IBM to save it's business had to merge with Red hat almost 50% 50% in 2018.
Microsoft it's security and cloud offering had to, open source it's .net framework, aquire GitHub, ditch Visual Studio fot Visual Studio Code,
ARM is eating the world, it over hauled the x86_x64 architecture, and became the Defacto architecture.
We can go on and on and on and on,that the Open Source business model, became necessary to survive in tech, not just to exist.
If you don't open it, they will eat you up.
Linux only took off during the dotcom days as IBM, Oracle and Compaq started adopting it into commercial workloads, back in 2000.
Visual Studio Code isn't in the same ballpark as Visual Studio. It was already an Azure project, as the Monaco editor, and it was a way to kill Atom.
ARM is only successful on mobile devices and Apple hardware.
If you mean ARM on server, the most successful company, Ampere, is largely owned by Oracle, and there are some ongoing discussions about a full acquisition.
Your "only" is funny. That is by far the biggest computing market worldwide.
I was using VM systems running on PCS from 1989 (OS/2) Linux only started in 1991 and did not take off for say 10 years, by then Windows NT existed.
So VM was necessary for Linux but was not the reason for it taking off.
In my experience Linux came in for servers replacing other Unix servers. Windows NT servers continued for some time.
As for desktop you still need Excel and to a lesser extent Word and these are still best on Windows.
Had Microsoft known better, and Linux would never taken off on PC.
Paying for software was never an issue back then, piracy was quite common, you could get whatever you wanted on the countries where street bazaars are a common thing.
Check the list, make your order, come around the following week.
How has Microsoft ditched VS for VSCode? VS is lightyears ahead in features and performance.
The two are not even remotely comparable. VSCode is a text editor that wants to be an IDE, but if you work with C++ or .NET you're shooting yourself in the foot if you use VSCode.
VSCode is not a serious alternative to VS or other IDE's like JetBrains Rider.
If anything, the x86 world was more open and more compatible. We have enterprise distros running on both Intel and AMD, supported by their hardware makers. Who in their right mind runs 3rd party Linux distributions on smartphones in production environments (i.e. the CEO's smartphone)?
GitHub is not open source.
> Whilst Visual Studio Code is "open-source" (as per the OSD) the value-add which transforms the editor into anything of value ("what people actually refer to when they talk about using VSCode") is far from open and full of intentionally designed minefields that often makes using Visual Studio Code in any other way than what Microsoft desires legally risky...
Without that leak we would not have the ecosystem evolving around Llama.
NeXTSTEP was 4.3BSD plus Mach, using Display Postscript as its windowing system and TIFF as its image format, supporting transparency for icons. macOS is FreeBSD plus Mach, using Display PDF as its windowing format and PNG as its image format, supporting transparency for icons. Basically NeXTSTEP but every component upgraded to its then-modern equivalent. (Except Objective C, they kept that.)
> Bell Labs did the same with Unix, but Unix was still not open source. This is why we run GNU/Linux today, not Unix™.
I know pretty well how NeXTSTEP used to be, my graduation project was to port a visualization framework from NeXTSTEP/Objective-C to Windows/C++.
The fact that UNIX™ later went on to become a compatibility specification, not a specific implementation, is irrelevant to the analogy.
Meanwhile, we continue to pour money into Oracle licenses, not just for basic access but for additional features—like enabling data reading and analysis on the Oracle-embedded database in our main app. And, if we need to allocate more CPU cores on our VMs, we face yet another round of licensing fees.
Sometimes you don’t need much support. Yet pay tons of money.
Why was PostgreSQL not an option according to management? I would not take their dismissal at face value. I'd want to know why not. But that might be Dutch culture.
I guess what ticks me off a bit is the trope of dissing on management for saying 'no' but leaving out all the relevant context that might show management to be right.
Don't get me wrong, I've seen my own fair share of bad management. But it's not so black and white when it comes to grand sweeping decisions like "should we invest in PostgreSQL or keep paying Oracle big license fees?"
Why? So we'll have someone to blame when things inevitably go wrong? In my experience, the people who like to say the buck stops with them are nowhere to be found when that happens.
I much prefer organizations focussed on actually getting things right, instead of worrying about who takes the blame.
Say, if the org runs Postgres in-house, there's a mighty chance that an intern somewhere might decide to ...test things out in a creative way.
Perhaps the idea of outsourcing that to Oracle is that Oracle has the processes/controls to rein in such interns. As opposed to e.g. a hospital having to create such processes/controls.
(Oracle is still a bad idea IMHO, just slightly less so comparatively)
Do you know of any examples of that happening?
A good example is the GIS industry where ESRI (ArcGIS) dominates. In Europe the open source qGIS is generally an acceptable alternative despite less 'support'. In America its hard to find anyone using qGIS and ESRI is basically a monopoly.
> An Open Source experiment meanwhile is typically operated by an enthusiastic hobbyist with borrowed equipment. Rolled out without training and without professional support, by someone who likely did this for the first time, it’s no wonder things often don’t work out well.
> After the experiment, the faction was disappointed and concluded that Nextcloud was no good. And that was also their lived experience. “Let’s not do that again!”
This is a rhetorical trick known as implication or insinuation. By presenting information indirectly, the author prompts readers to make a connection themselves without explicitly stating it.
The author implies that the European Parliament's failed experiment with Nextcloud was due to a lack of professional resources and expertise, suggesting it was handled similarly to typical open-source projects led by hobbyists without proper support. However, he doesn’t provide any factual evidence that the Parliament’s Nextcloud experiment actually lacked professional resources, training, or adequate equipment. Instead, he hints at this by describing common issues with open-source setups, leaving readers to assume the experiment suffered from similar shortcomings.
I would have appreciated some facts, or even sources for his claims, but there are none. And I couldn't find any information about the Nextcloud deployment having failed.
I hate to break it to you but it takes time to implement closed source solutions as well. They also always have terrible documentation, because they make money on support.
Purely open source stuff lives and dies on how easy it is to start up.
Closed source paid stuff doesn't need to be easy. Often a decision has been made before implementation, and there are people to help you through it.
It's also easier to get approval for open source most of the time because there isnt a new bill, just my time.
I usually reach for open source first.
[1]https://en.wikipedia.org/wiki/LiMux
[2]https://arstechnica.com/information-technology/2024/04/germa...
Hard to be an alternative when you serve the same master.
This isn't charity, they are literally using more OSS software than they produce their own software. By several orders of magnitude in most cases. Companies like Google have many millions of lines of code in proprietary in house code. But they depend on an even larger amount of code in OSS form.
E.g. Android and Chrome OS are based on Linux. Those products are built on many thousands of open source packages. And of course Google is contributing to lots of them and created a few themselves. Chrome is open source because webkit was open source because Apple forked KHTML from the KDE project.
Open source without commercial companies contributing would be much more of a fringe thing.
VC funded OSS companies are a bit more challenging. These companies are perpetually confused about their licensing and need to keep things proprietary and open at the same time. These projects get a lot of attention because of the VC money but technically they only represent a tiny fraction of the OSS community.
I don't think this is actually true:
1. The Google codebase is on the order of billions of lines of code, not millions.
2. It's basically all written in house, from the threading libraries and core standard libraries up. The parts that are open source (e.g. Linux, OpenJDK) are very small compared to the code they've written themselves.
ChromeOS and Android are open source, but they aren't even close to being the bulk of their codebase.
If Linux had never existed they'd have found some alternative, probably either a bulk licensing deal with a proprietary UNIX vendor or they'd have used Windows as the closest cheap Intel based alternative. Then they'd have put funding into developing their own in-house serving OS a lot earlier.
Source: I worked there.
> Chrome is open source because webkit was open source because Apple forked KHTML from the KDE project.
Chrome is open source for strategic reasons and because the executives in charge wanted it to be. There's no particular reason it has to be open. Safari and Edge aren't.
I think you are grossly underestimating how dependent both companies are on various open source projects. It's definitely true that they also do a lot of in house code of course; and they also contribute a lot of their own projects. And of course especially Google is a repeat offender when it comes to creating a lot of dead projects, reinventing the wheel, etc. It looks like their attempt to create their own operating system kernel is slowly dying now. Fuchsia is all but dead at this point. So they are back to Linux being their only future. There's the whole Kotlin ecosystem, which they helped create, which is starting to compete with flutter. And so on.
I'm not really underestimating anything. I worked on the Google codebase for years. It has very little dependence on open source code relative to its overall size.
My conjecture is that open source is polished enough for most customers to use when there are commercial interests implied. Linux on the server is a resounding success, Linux desktop not so much.
That is the thing, what really won on server and embedded was UNIX/POSIX, and while GNU/Linux is the cheapest and more flexible way to achieve that, it isn't the only one, and the best experience is anyway with vendor custom distributions with their special sauce, not the pure FOSS one.
I think one can attribute many things to the success of Linux (incl. POSIX) but it's not about one single thing and the whole shouldn't be discounted.
It is no different than using managed Kubernetes, or doing everything from scratch instead.
And I wouldn't agree Linux desktop is unsuccessful. It's actually growing quite a bit in the last few years. And of course ChromeOS is also Linux based and capable of running Linux software. Likewise, MS bundles Linux with Windows and it is widely used by developers using Windows that way.
But even without that Linux Market share is now 4.5%. Quite a few gamers are discovering Linux works pretty well lately. With ChromeOS included it's closer to 6-7%. Linux on the Desktop is bigger than ChromeOS. I'd say it is getting better.
https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
People have to put food on their table and can't work for free. Someone has to pay for that work. Nobody will pay for it if he can't extract some benefits from doing so.
Then the whole issue with non-copyleft licenses, that are nothing other than the old Whateverware or Public Domain licenses from the 16 bit home computer days.
We already had access to source code back then.
And for a large crowd this is already good enough, they aren't into it for religious definitions.
I remind you all Emacs powered some German airline's ATC in the early 90's, and it used to be used under Amazon for tons of stuff thanks to its easy widget UI to achieve tasks with very little Elisp.
You can use Google docs for free so it takes some dedication to self host that and pay for the server.
Now if big tech charged for everything things would be more like the old days where you might use small tech, such as a local hosting provider that does open source installs.