2023 and 'the Eternal Struggle Between Proprietary and Open Source Software' (techcrunch.com) 55
TechCrunch argues that in 2023, "established technologies relied on by millions hit a chaos curve, making people realize how beholden they are to a proprietary platform they have little control over."
The OpenAI fiasco in November, where the ChatGPT hit-maker temporarily lost its co-founders, including CEO Sam Altman, created a whirlwind five days of chaos culminating in Altman returning to the OpenAI hotseat. But only after businesses that had built products atop OpenAI's GPT-X large language models (LLMs) started to question the prudence of going all-in on OpenAI, with "open" alternatives such as Meta's Llama-branded family of LLMs well-positioned to capitalize.
Even Google seemingly acknowledged that "open" might trump "proprietary" AI, with a leaked internal memo penned by a researcher that expressed fears that open source AI was on the front foot. "We have no moat, and neither does OpenAI," the memo noted.
Elsewhere, Adobe's $20 billion megabucks bid to buy rival Figma — a deal that eventually died due to regulatory headwinds — was a boon for open source Figma challenger Penpot, which saw signups surge amid a mad panic that Adobe might be about to unleash a corporate downpour on Figma's proverbial parade. And when cross-platform game engine Unity unveiled a controversial new fee structure, developers went berserk, calling the changes destructive and unfair. The fallout caused Unity to do a swift about turn, but only after a swathe of the developer community started checking out open source rival Godot, which also now has a commercial company driving core development.
Thanks to wiggles (Slashdot reader #30,088) for sharing the article.
Even Google seemingly acknowledged that "open" might trump "proprietary" AI, with a leaked internal memo penned by a researcher that expressed fears that open source AI was on the front foot. "We have no moat, and neither does OpenAI," the memo noted.
Elsewhere, Adobe's $20 billion megabucks bid to buy rival Figma — a deal that eventually died due to regulatory headwinds — was a boon for open source Figma challenger Penpot, which saw signups surge amid a mad panic that Adobe might be about to unleash a corporate downpour on Figma's proverbial parade. And when cross-platform game engine Unity unveiled a controversial new fee structure, developers went berserk, calling the changes destructive and unfair. The fallout caused Unity to do a swift about turn, but only after a swathe of the developer community started checking out open source rival Godot, which also now has a commercial company driving core development.
Thanks to wiggles (Slashdot reader #30,088) for sharing the article.
No control over open source either (Score:4, Insightful)
Have you ever tried to contribute code to a large open source project? Good luck with that! They have their little group of developers that are *in* and everybody else can just go away. It's not like you can go submit a pull request to Newtonsoft JSON and hope to see it in the next set of release notes.
Re:No control over open source either (Score:4, Interesting)
Basically there's three camps.
Proprietary = This is our stuff, and no outside help is wanted
GPL = This is owned by all contributors, and no outside help will be accepted without also making it fall under GPL
BSD/MIT/PD = This is a product, do whatever with it, no contributions will be accepted, if you want new features, fork it and rename it.
Source code can be developed under any of the three models, but the first two will poach code from the third without contributing anything back.
However "AI models" are not source code. There is no way to "open" a model. You can only release a blackbox. Even two different training processes on the same data set will create a completely different model.
The way forward for AI models is to make models that can trained or run inference on 8GB consumer GPU's or CPU's to be public. The best models will win when tested against standard criteria. To prevent models from being "faked" (eg FANCY model is really X model that has been trained further on FANCY dataset but is otherwise still X.) Which is the case with the LLAMA deviations, the actual training datasets and code/configuration files need to be included with the models.
It's also needs to be stated that that certain kinds of AI models can be swapped with others and still use the same inference engine, this can result in improved performance without needing to retrain the model for the new code.
This is why open source products may instead wind up supplanting proprietary ones, because the audit trail on the datasets used will be clear, and legally safer than a proprietary one that nobody knows what exactly it has ingested.
Re:No control over open source either (Score:4, Insightful)
Even in your GPL model, yes, you can fork the repo, but there's not guarantee you can actually contribute to the repo. Somebody still controls it, and if they don't want your contribution, too bad. And saying "well you can just fork it" is a big ask, because then you're responsible for maintaining it, and most open source contributors don't want to maintain an entire project, they just want to be able to touch it here and there.
As for AI, yes, the engine is code, but the training is where the real IP is. And none of the big boys are giving THAT away.
Re:No control over open source either (Score:5, Funny)
most open source contributors don't want to maintain an entire project, they just want to be able to touch it here and there.
That's how a lot of guys feel about women, too.
Re: (Score:2)
You just want to make a small change and not maintain it, because you want someone else to do the maintenance for you.
There is no getting around it. Code needs maintenance, someone has to put in the work.
Re: (Score:2)
I think you might be imagining a small project run by "some guy." If that's what you're doing, by all means fork the repo.
A lot of bigger projects are maintained by whole teams of people, sometimes even major corporations. Chromium, .NET Core, Android, and Linux are some examples. It's not practical for most users to fork such a large project for their own purposes, and try to maintain it. And in such cases, it's likely that their special use case won't be accepted as a priority by the main developers of th
Re: (Score:1)
Commercial software, on the other hand, depends on customers being happy, and are more likely to do what it takes to keep them happy.
How much proprietary software have you used? Have you heard of Windows 95? Do you think Windows has always been done to make customers happy? I really don't think some, most, or all commercial software is done to keep customers happy. It seems to be there to make money and maintain control.
Re: (Score:2)
YOU are not an ideal customer of Windows. Microsoft has built its OS mainly to target two groups: 1) people who are mostly computer illiterate, who can barely operate a spreadsheet, and 2) enterprise IT departments who want to tweak all kinds of security settings and manage the systems centrally. Those are the people Microsoft tries to keep happy. It's no accident that the vast majority of home computers, and enterprise workstations, run Windows.
Developers, on the other hand, often revert to the command lin
Re: (Score:2)
Re: (Score:2)
Yeah, I know your free software paradise is gone, sorry about that.
Re: (Score:2)
Gone? How?
Free software does everything I need (there is literally nothing I need to do on a computer that doesn't have at least one, or more often multiple, free software options), doesn't require paying rent, doesn't lock up my data, won't force me to upgrade to an incompatible version or prevent me from reverting back to an older version or switching to an alternative program, and won't suddenly vanish one day.
It also won't spy on me or sabotage my system or my data if it detects that I'm doing something
Re: (Score:2)
I'm glad open source meets all of your needs. Don't kid yourself, you are still being spied on, especially if you use a web browser or a smartphone. But that aside, YOU are not representative of the needs of a typical business.
Take office suites, for example. LibreOffice is probably sufficient for your needs. But businesses have moved to a much more collaborative way of developing documentation and other documents. With MS Office or Google Docs, they can all make updates to the same shared documents, in rea
Re: (Score:2)
I'm NOT being spied on by free software. What telcos and web site do are, to a large extent, outside of my control (although I can block third-party cookies and use ad-blocking and javascript disabling plugins in my web browser to minimise the exposure - and just not visit some sites).
I control what I can and take sensible precautions as best I can everywhere e
Re: (Score:2)
Perhaps your open source software isn't designed to spy on you, but that doesn't mean it can't be made to spy on you. And you'd never know.
As for AI, it does actual work for me. It might be doing it by leveraging some less-than-magical mumbo-jumbo, but the tool still accomplishes work and saves me time. I'll take it.
And as for modern software, just because it's been updated recently, doesn't make it "modern." As an example, I use GnuCash to keep track of my finances. It's updated every quarter, but it is by
Re: No control over open source either (Score:4, Interesting)
My experience is that there is no correlation between use of copy left (GPL) and BSD style open source as to whether they will entertain patches in a reasonable timeframe. Their expectations around what a commercial entity will do with their project obviously differs, but there are plenty of GPL projects that don't find it in them to accept contributions and plenty of BSD projects that are highly responsive to review pull requests.
Proprietary source licenses much like FOSS (Score:2)
Basically there's three camps.
Proprietary = This is our stuff, and no outside help is wanted
That is not accurate. There are proprietary options that have many of the features of FOSS. You describe a proprietary binary license, but there is sometimes a proprietary source license. Especially for libraries. With a source license you are free to modify and build your own code for your distribution. Just like FOSS. However unlike FOSS, your customer that get's your binary has no right to the source code.
So proprietary can extend source code rights one generation, to direct customers only.
Where FOSS
Re: (Score:2)
1. Why call it "poaching" when the entire purpose of BS
Re: No control over open source either (Score:3)
You always have the option to fork. It may not be a desired outcome, but it's at least an option.
When a company takes the rug out from "ethereal"? Fork to Wireshark. Xfree86 license change? Xorg comes along.
If VMware withdraws your product when broadcom decides it's not worth it? Well you have no options.
Sure a lot of projects do not do a code review and accept patches from outsiders easily, but you have a fair shot of getting an important fix in, or triggering the insiders to create an equivalent solu
Re: (Score:2)
Forking isn't really an option, unless you're prepared to take on management of the entire forked project. Oftentimes, all a contributor wants to do is fix one pesky bug that is affecting their specific use case, not take on the whole project.
Re: (Score:2)
You can also maintain a patch-set for much lower effort.
Re: No control over open source either (Score:2)
Re: (Score:2)
And so now they have a poorly-tested fork of the Linux kernel. Nice.
Re: (Score:2)
Of course forking is an option. A fork can be *really* lightweight. In your case, you make a fork, make your change and pull request, and if you have headwinds you just periodically rebase your fork, checking if your fix has been included or an equivalent. You don't have to accept pull requests, you don't have to field issues. You just have to let git do the rebasing ever so often and track the upstream activity. The Xorg/Wireshark are examples where the entire community was getting cut off, and someone
Re: (Score:2)
If the project is small enough, and your changes are small enough, this strategy would work fine.
Re: (Score:2)
Forking isn't really an option, unless you're prepared to...
actually do it?
Oftentimes, all a contributor wants to do is fix one pesky bug
So you can't do anything, because the average person doesn't want to do everything? What sort of idiot argument is that?
Re: (Score:2)
It's a practical argument.
Let's say I'm an app developer, and my app won't work because of something I perceive to be missing in Android. So I fork Android and add my feature. My job just got a whole lot harder, and I STILL can't install my app on other people's Android phones.
Re: (Score:2)
That's a fucking stupid analogy, if you were an app developer you'd know a bunch of reasons why, too.
Re: (Score:2)
And yet, *you* couldn't name a single reason it's a "stupid" analogy. So you must not be an app developer either.
You are right about one thing, I don't personally (currently) develop Android apps.
Re: (Score:1)
Have you ever tried to contribute code to a large open source project? Good luck with that! They have their little group of developers that are *in* and everybody else can just go away. It's not like you can go submit a pull request to Newtonsoft JSON and hope to see it in the next set of release notes.
You can contribute quite easily to open source projects of all sizes, but you do have to keep in mind that:
Re: (Score:2)
You can contribute quite easily
That all depends on precisely who is running the project, and how receptive they are to outsiders. Some might easily let you in, I suppose, but since people put a lot of effort into these things, they won't commonly be so willing.
As for forking, that's only an option if you (or your company) are willing to take on ALL of the maintenance for the project. Much of the time, people just want to fix a bug or add a feature that they specifically are in need of, they don't want to be the full owner of the project.
Re: (Score:2)
Forking maybe not be the best option, but its an option. If a closed source project doesn't want your fix then you are just screwed. Also you may not want every fix that is provided, it can break your stuff just as much as fix it.
While you may say closed source software may be more motivated to do your fix because they are getting paid, their is nothing stopping you paying open source developers either.
Re: (Score:2)
Yes, a closed source project a generally motivated by the desire for profits, to keep their customers happy. This is precisely why RHEL exists. Businesses want product support, and they will pay for it. They don't want to *fork* Linux to get the features or fixes they want.
If you are doing business with a vendor that can't keep their own code maintained, you're doing business with the wrong vendor.
Re: (Score:1)
If you are doing business with a vendor that can't keep their own code maintained, you're doing business with the wrong vendor.
Open source definitely tends to be the slow-and-steady mode more than anything else, but it's worth it over the long haul. You should focus on creating patches and a CI/CD pipeline to apply them when there's new upstream changes if you want custom changes they won't accept, you never have to worry about it beyond a standard update that way.
Re: (Score:2)
For small projects this probably works fine. For big ones, like Android or .NET, it's a much bigger ask to maintain your own patches.
Re: (Score:1)
Much of the time, people just want to fix a bug or add a feature that they specifically are in need of, they don't want to be the full owner of the project.
Personally, this is why I prefer FreeBSD. If you host your own ports collection (not trivial to set up correctly) you can very easily set your whole network to pull from it (via pre-compiled packages or source) and create source patches which only apply to your network. I have several to Blender I've written over the last decade along with some other apps (both user-side like that and server-side, around 2,500 in all) and in that time there's been one upstream change which broke things to the point it req
Re: (Score:1)
Re: (Score:2)
In other words, you don't have creative control over the original trademarked product, but you still have the option to save the code from dickish organizations.
Re: (Score:2)
The LibreOffice fork worked because there is still a whole community of developers dedicated to maintenance of the project. That's a lot different than you trying to fork it yourself.
Re: (Score:2)
To preempt some inevitable replies: the whole "Whaaa! Firefox moved a button to another location" or "Whaaa! Firefox broke compatibility with the old plugin system that made Firefox crash all the time" are not important concerns. There was a short-lived fork called Waterfox, but soon people realised the new plugin system was just fine.
But important complaints do get enough people willing
Re: (Score:2)
What you have said is true. And this is not a difference between commercial, closed source development, and open source development. Closed-source software also gets "fixed" if enough people have a problem.
Re: (Score:2)
Re: (Score:2)
.Those complaints would immediately lead to a well-maintained fork in FOSS
Would it though?
Re: No control over open source either (Score:2)
Re: (Score:2)
Even with the community-driven projects, you have to become part of the community to be able to make changes, and the bar of entry is often quite high.
We have no moat (Score:2)
"We have no moat, and neither does OpenAI," the memo noted.
This is strangely comforting somehow.
No mention of Red Hat (Score:2)
How did this article not mention anything about Red Hat / IBM in 2023?
Re: (Score:2)
How did this article not mention anything about Red Hat / IBM in 2023?
With the classic ignore the inconvenient truths.
Re: (Score:2)
Why would it need to be mentioned in this context?
Re: (Score:2)
How did this article not mention anything about Red Hat / IBM in 2023?
Probably because nothing significant happened. 4% of RedHat has laid off, that happens in every big company on a regular basis. It resulted in more shouted hyperbole than average, because that just comes with the OSS userbase.
Note that IBM has released many really important open source projects over the years, and continues to contribute to the Linux Foundation.
IBM is mostly a cloud services company these days, and their whole stack is open source. If you build your cloud solution to run on IBM, you can swi
Software...who cares...it DATA thats important (Score:1)
I STRONGLY object my data being held ransom to proprietary file formats, keeping me "locked in" having to cough up monthly/yearly.
If proprietary is better than OSS, and the price is realistic I will part with my money with no complaints.
What I will NOT do is give anyone blackmail rights over the stuff I create.
Re: (Score:2)
Data is software.
And software processes data.
File formats being proprietary is irrelevant, reverse engineering for compatibility purposes is legal. LibreOffice can read and write OLE data better than Microsoft Office can.
Cloud services are ransomware. No matter if the software is proprietary or open, you don't run it anyway. You pay for access to your own data, regardless of what format you choose.
Open source is better because in case the supplier goes belly up, you can still get support. You can also a
My Own Preference For Open Source (Score:4, Interesting)
Notice that the fact that it's free (as in beer) is not among my list of reasons, although it certainly doesn't hurt. However, I have no problem paying handsomely for quality proprietary software as long as the only DRM is nothing more than a serial number and the vendor seems committed to supporting their product for quite some time. Oh, and as long as the vendor isn't on my ever-growing shit-list.
What "perils"? (Score:2)
TFA doesn't mention any misuse of open source software.
The closest thing to "perils" might be the licensing changes it describes, but...well, adjust. It's not like "forcing major changes that make everybody re-evaluate whether they want to keep using it" never happens with commercial software.
mark (Score:2)
marking for future reference