The Dead End(redmonk.com)
redmonk.com
The Dead End
https://redmonk.com/sogrady/2022/09/23/dead-end/
35 comments
By way of disclosure, I'm the author of the linked piece.
That said, having spoken to most of the parties involved prior to their decisions to relicense, I can tell you that investors were a major motivating factor in many if not all cases.
In certain instances, this was because a particular investor convened private meetings between groups of commercial backers of open source projects - both portfolio companies and not - to propose non-open source alternatives, and companies went along with it. In other cases, board members were swayed by arguments from these same investors. Either way, pressure to try and replicate proprietary software profit margins from investors was a significant, if not sole, motivating factor in the decisions in question.
If you look at the history of investors in many of the companies involved the pattern is notable.
That said, having spoken to most of the parties involved prior to their decisions to relicense, I can tell you that investors were a major motivating factor in many if not all cases.
In certain instances, this was because a particular investor convened private meetings between groups of commercial backers of open source projects - both portfolio companies and not - to propose non-open source alternatives, and companies went along with it. In other cases, board members were swayed by arguments from these same investors. Either way, pressure to try and replicate proprietary software profit margins from investors was a significant, if not sole, motivating factor in the decisions in question.
If you look at the history of investors in many of the companies involved the pattern is notable.
Why do you believe open source developers should attach themselves to the same 'Companies who generate billions in revenue using open source products'?
I think that would negate one of the primary attractions of being an open source developer, not being financially tied, or have any kind of obligations, to any specific group.
Also, being able to credibly claim that they are not financially biased towards any outcome, position, decision, etc...
I think that would negate one of the primary attractions of being an open source developer, not being financially tied, or have any kind of obligations, to any specific group.
Also, being able to credibly claim that they are not financially biased towards any outcome, position, decision, etc...
Splendid isolation is a delusion that makes the world a more dangerous place.
> The first phase is one in which a given project is released into the world with a legitimate, OSI approved software license. It competes in the market with other, similar projects and it succeeds or fails on its merits, or more likely, the hundred other ancillary factors that are, in the aggregate, more determinative than its merits.
I think this part doesn't go far enough -- intelligent investors are pouring in money during this phase, and accelerating growth of projects earlier and earlier. This enables slightly backed projects to out-compete others, market more heavily and discourages authors of competing OSS projects.
I haven't seen the "switch" happen so much personally (generally a CLA was a good enough indicator) but I want to point out that this also happens without the involvement of investors. Sometimes F/OSS developers realize how much value they're putting out without receiving adequate compensation and decide to monetize their software, as is their right.
It should be expected that the field couldn't live on goodwill alone -- there just aren't enough Stallmans out there. The previous era may have been unsustainable.
I say this as someone who tries to make profit from open source software that I did not create. It is healthy for developers to recognize the value they are producing and withhold it if they so choose. It doesn't make sense to begrudge someone for making awesome software that they expect me to pay for -- if I care that much then I can try and generate the value they've generated, or pay for the value they've generated.
That said, I still think the future of F/OSS is AGPL[0], not SSPL/BSL/etc. Forcing improvements to be contributed back seems to scare companies that want to exclusively use the product selfishly.
Many projects are creating value and going for fully F/OSS licenses anyway, because of a belief in the value of community (whether cynically or not). Those projects end up winning because leveraging a sea of contributors almost always beats tens/hundreds/thousands of closed source devs in the general case, with good guidance.
[0]: https://vadosware.io/post/the-future-of-free-and-open-source...
I think this part doesn't go far enough -- intelligent investors are pouring in money during this phase, and accelerating growth of projects earlier and earlier. This enables slightly backed projects to out-compete others, market more heavily and discourages authors of competing OSS projects.
I haven't seen the "switch" happen so much personally (generally a CLA was a good enough indicator) but I want to point out that this also happens without the involvement of investors. Sometimes F/OSS developers realize how much value they're putting out without receiving adequate compensation and decide to monetize their software, as is their right.
It should be expected that the field couldn't live on goodwill alone -- there just aren't enough Stallmans out there. The previous era may have been unsustainable.
I say this as someone who tries to make profit from open source software that I did not create. It is healthy for developers to recognize the value they are producing and withhold it if they so choose. It doesn't make sense to begrudge someone for making awesome software that they expect me to pay for -- if I care that much then I can try and generate the value they've generated, or pay for the value they've generated.
That said, I still think the future of F/OSS is AGPL[0], not SSPL/BSL/etc. Forcing improvements to be contributed back seems to scare companies that want to exclusively use the product selfishly.
Many projects are creating value and going for fully F/OSS licenses anyway, because of a belief in the value of community (whether cynically or not). Those projects end up winning because leveraging a sea of contributors almost always beats tens/hundreds/thousands of closed source devs in the general case, with good guidance.
[0]: https://vadosware.io/post/the-future-of-free-and-open-source...
> That said, I still think the future of F/OSS is AGPL[0], not SSPL/BSL/etc. Forcing improvements to be contributed back seems to scare companies that want to exclusively use the product selfishly.
And yet, according to Mongo and ElasticSearch, the AGPL doesn't help them actually sell their software in the only way they think is profitable - as a SaaS platform - since it is not creating the type of moat they were hoping for, where they would be the only ones able to offer it as a managed service. AWS was eating their lunch with their own product despite the AGPL, which led to their new license.
And yet, according to Mongo and ElasticSearch, the AGPL doesn't help them actually sell their software in the only way they think is profitable - as a SaaS platform - since it is not creating the type of moat they were hoping for, where they would be the only ones able to offer it as a managed service. AWS was eating their lunch with their own product despite the AGPL, which led to their new license.
> And yet, according to Mongo and ElasticSearch, the AGPL doesn't help them actually sell their software in the only way they think is profitable - as a SaaS platform - since it is not creating the type of moat they were hoping for, where they would be the only ones able to offer it as a managed service. AWS was eating their lunch with their own product despite the AGPL, which led to their new license.
You're right -- you're discussing the future of "proprietary software" there -- not the future of F/OSS.
Why I say that the future of F/OSS is AGPL is because increasingly smaller creators who know the value of their work are building software with an eye to profitability down the road (or at least avoiding exploitation).
This is also why I say that the AGPL is misunderstood -- it does not stop people from running a competing service, it stops them from improving your software (usually for their competing service) and not contributing the changes back. For now, it does serve to discourage most corporations though I think that will wear away over time.
Still, AGPL is juuuust at the edge of F/OSS, that's where the frontier will likely be -- the step before BSL/SSPL/Elastic and similar licenses.
Libraries are a completely different matter though!
You're right -- you're discussing the future of "proprietary software" there -- not the future of F/OSS.
Why I say that the future of F/OSS is AGPL is because increasingly smaller creators who know the value of their work are building software with an eye to profitability down the road (or at least avoiding exploitation).
This is also why I say that the AGPL is misunderstood -- it does not stop people from running a competing service, it stops them from improving your software (usually for their competing service) and not contributing the changes back. For now, it does serve to discourage most corporations though I think that will wear away over time.
Still, AGPL is juuuust at the edge of F/OSS, that's where the frontier will likely be -- the step before BSL/SSPL/Elastic and similar licenses.
Libraries are a completely different matter though!
I think that the AGPL would've been a better solution for elastic search, but in some ways I don't think it goes far enough.
Look, for example, at google doing an end-run about the GPL by using a license that restricts forking rights on Android.
I also want the license to provide an interoperability clause - if it's OSS I should be able to build and deploy a fork.
Look, for example, at google doing an end-run about the GPL by using a license that restricts forking rights on Android.
I also want the license to provide an interoperability clause - if it's OSS I should be able to build and deploy a fork.
It's been said that the "GitHub generation" of developers cares more about the practical aspects of openness than rigid definitions. I'm not of that generation, but I enjoy watching these battles from the sidelines. Don't contribute to any software where there's a risk the stewards will licence switch on you. Or do, if you need to get a fix upstream and it's the most expedient solution. It's a business decision like many other we need to make.
> Don't contribute to any software where there's a risk the stewards will licence switch on you
If you contribute, you own copyright to your contribution and the software can't be relicensed without your approval (or removal/reimplementation of the parts you added).
The trick is to not grant the copyright assignment (ie. gift the maintainers your copyright).
As an example, here's what MongoDBs contributor agreement[0] says:
> By submitting a contribution, you assign to MongoDB all right, title and interest in any copright you have in the Contribution, and you wave any rifghts, including any moral rights, database rights, etc. that may affect our ownership of the copyright in the Contribution.
Other projects have similar language. If you contribute a project and sign something like that, you're not contributing to an open source project[1] - you're working for that corporation for free.
[0] https://www.mongodb.com/legal/contributor-agreement
[1] With one exception: FSF also requires you to sign over the ownership and there's zero chance they'll turn corporate.
If you contribute, you own copyright to your contribution and the software can't be relicensed without your approval (or removal/reimplementation of the parts you added).
The trick is to not grant the copyright assignment (ie. gift the maintainers your copyright).
As an example, here's what MongoDBs contributor agreement[0] says:
> By submitting a contribution, you assign to MongoDB all right, title and interest in any copright you have in the Contribution, and you wave any rifghts, including any moral rights, database rights, etc. that may affect our ownership of the copyright in the Contribution.
Other projects have similar language. If you contribute a project and sign something like that, you're not contributing to an open source project[1] - you're working for that corporation for free.
[0] https://www.mongodb.com/legal/contributor-agreement
[1] With one exception: FSF also requires you to sign over the ownership and there's zero chance they'll turn corporate.
They can only change the license of future contributions alone.
Your contributions are still protected by your original license, unless you agreed to some other license in parallel (such as via a contributor agreement).
Therefore, by including your work without respecting the terms of your license (such as the MIT license text inclusion), they are violating your copyright.
As such, any contributor agreement should make you think twice.
Your contributions are still protected by your original license, unless you agreed to some other license in parallel (such as via a contributor agreement).
Therefore, by including your work without respecting the terms of your license (such as the MIT license text inclusion), they are violating your copyright.
As such, any contributor agreement should make you think twice.
I don't see the real problem here. By its nature, FOSS software cannot be monopolized. If party A decides to replace a legit license with one of these commercial source-available licenses, just fork the last commit using the original license and develop from there.
Oh but wait -- the community, the contributors, the users are all attached to the original project. Well, that's competition: make your version better, advertise the licensing issue; poach the original community.
Case in point:
Oh but wait -- the community, the contributors, the users are all attached to the original project. Well, that's competition: make your version better, advertise the licensing issue; poach the original community.
Case in point:
Your case in point dropped off, but Percona (MySQL and MongoDB distributions) and until a couple of years ago MariaDB fell into this category I think.
Was going to mention MongoDB. the day they announced the change, I created a fork (https://github.com/danx0r/mongo). Now, if a client wants mongoDB I just install this version on a cpu somewhere and go from there. If the project really needs more up-to-date versions of the core DB or the cloud tools, we have a discussion about the restrictions that apply to later versions.
I think this does not really constitute pump-and-dump or loss-leader behavior because the code generated during the open license phase has real value to the community.
One thing I think could use more analysis is, does Mongo's license change breach any copyleft provisions of the original license? I recall they started with the permissive Apache license but prior to the last change 4 years ago they were AGPL.
I think this does not really constitute pump-and-dump or loss-leader behavior because the code generated during the open license phase has real value to the community.
One thing I think could use more analysis is, does Mongo's license change breach any copyleft provisions of the original license? I recall they started with the permissive Apache license but prior to the last change 4 years ago they were AGPL.
What happened a couple of years ago with MariaDB?
That was a bad explanation on my part, sorry. They are still open source!
But they diverged from keeping fully aligned with MySQL developments AFAIK so are no longer a fork/distribution as they are forging their own path.
So I was being unclear, the "until a couple of years ago" was referring to divergence rather than a change in license.
So I was being unclear, the "until a couple of years ago" was referring to divergence rather than a change in license.
Thanks for the reply. I followed this quite closely at the time, but not for the last few years. Glad to hear they're still open. Features will get us all in the end, eh? :)
That's classic dumping, though. Give away your product for free until you dominate the market and then try to monetize your market share.
Huh? What's an example of this? The author talks about the phenomenon like it's so widespread it hardly needs to be explained, but I honestly have very little idea what they're even talking about. Every major open-source project I'm aware of is still permissively-licensed
Recently Akka [0], a 12K star project.
[0]: https://github.com/akka/akka/pull/31561
[0]: https://github.com/akka/akka/pull/31561
There seems to be a fork trying to establish itself: https://cwiki.apache.org/confluence/display/INCUBATOR/PekkoP...
I think github could do a lot better job in cases like this of highlighting active forks, to make it possible for communities to coalesce around OSS forks of projects that have switched to commercial licenses or have gone maintainer-less.
For an example, jq has gone without maintenance for a long time now, but it's very challenging to gain critical mass around a maintained fork, so the un-maintained fork remains state of the art.
For an example, jq has gone without maintenance for a long time now, but it's very challenging to gain critical mass around a maintained fork, so the un-maintained fork remains state of the art.
MongoDB, TimescaleDB, ElasticSearch come to mind, as high profile examples.
I do want to note Timescale's license is extremely generous:
https://github.com/timescale/timescaledb/blob/main/tsl/LICEN...
There's a marked difference between what they allow you vs Mongo (SSPL) and Elastic (Elastic license) -- see (b).
Also generally the Postgres ecosystem has in general seemingly found a way to strike a balance between creating immense value (point to a F/OSS DB that's better than Postgres) and enabling commercial success (Citus, 2nd Quadrant, EDB, Timescale, Supabase, Neon are all very successful)
I do agree with the overall trend though -- I already think the future is going to be AGPL[0] (but that's based partially on a misunderstanding of what AGPL does).
It remains to be seen if people will cynically make projects open source to start and then switch to something like SSPL/BSL/Elastic later, but the unintentional rug pulls will probably continue for a while.
[0]: https://vadosware.io/post/the-future-of-free-and-open-source...
https://github.com/timescale/timescaledb/blob/main/tsl/LICEN...
There's a marked difference between what they allow you vs Mongo (SSPL) and Elastic (Elastic license) -- see (b).
Also generally the Postgres ecosystem has in general seemingly found a way to strike a balance between creating immense value (point to a F/OSS DB that's better than Postgres) and enabling commercial success (Citus, 2nd Quadrant, EDB, Timescale, Supabase, Neon are all very successful)
I do agree with the overall trend though -- I already think the future is going to be AGPL[0] (but that's based partially on a misunderstanding of what AGPL does).
It remains to be seen if people will cynically make projects open source to start and then switch to something like SSPL/BSL/Elastic later, but the unintentional rug pulls will probably continue for a while.
[0]: https://vadosware.io/post/the-future-of-free-and-open-source...
Thanks for sharing this point of view. For those interested, I wanted to share this blog post that explains the Timescale approach in detail. https://www.timescale.com/blog/building-open-source-business...
Timescale's community manager.
Timescale's community manager.
Maybe an unpopular opinion, but I'm personally not against the principle of a "super AGPL" that requires apps built on a system like a database to be open source.
The problem with the SSPL, as I see it, is that it's incompatible with pretty much every other open source licence and software, possibly even running it on linux. Something similar that requires everything to be released under some kind of FOSS licence seems desirable, but I don't know if that could be defined legally.
The problem with the SSPL, as I see it, is that it's incompatible with pretty much every other open source licence and software, possibly even running it on linux. Something similar that requires everything to be released under some kind of FOSS licence seems desirable, but I don't know if that could be defined legally.
In the .NET world, the most recent example would be Identity Server.
Used to be open-source, became the defacto OAuth implementation, but now it's closed source.
Used to be open-source, became the defacto OAuth implementation, but now it's closed source.
Cockroach DB and MongoDB are some of the most famous examples.
This article consists of a few highly selective observations, glued together by make-believe.
Open source was the industry default? On what planet?
"Team, make everything open source by default, unless I tell you otherwise" --- said no CEO or other boss, ever.
We have a lot of open source; a lot of it is very advanced, and forms critical infrastructure, sure. But proprietary software has not gone away even slightly.
> Open source licenses, after all, offer the same equitable terms to all players, and limit neither competition nor usage.
Really? The sole proprietor of some GPLed program is on the same level as any other player?
And how can you write a lengthy article on these topics without even mentioning what is probably the biggest issue to free software: it is not some "bait and switch" where open source projects get relicensed. It's that much software people use is now a service. The user has no control whatsoever; they are not even getting to install a binary executable on their own machine. The licensing is irrelevant to the end user.
This entire article is about the bickering among developers: who gets what kinds of rights to which infrastructural pieces, with it being understood that everyone's shared goal is cobbing something together with those pieces in order to hold hostage the hapless users of some god forsaken SaaS application.
OK, so sure; if we put developer blinders on, open source is the default. My compiler is open source; my editor is open source; the OS is open source; the browser is open source; the database is open source. Hey open source is the default!
Meanwhile, Average Joe: social network isn't open source; webmail isn't open source; crap running in Joe's automobile isn't open source; Joe's phone isn't open source; Joe's TV streaming box isn't open source. Neither are the half dozen apps Joe relies on for this and that, or services like online banking. Almost not a single everyday use case or solution for the average user is open source. How can you talk about a default with a straight face. And this is just the consumer-facing stuff I'm talking about. For instance, let's switch to business. What enterprise runs their finances, operations and logistics on open source?
Open source was the industry default? On what planet?
"Team, make everything open source by default, unless I tell you otherwise" --- said no CEO or other boss, ever.
We have a lot of open source; a lot of it is very advanced, and forms critical infrastructure, sure. But proprietary software has not gone away even slightly.
> Open source licenses, after all, offer the same equitable terms to all players, and limit neither competition nor usage.
Really? The sole proprietor of some GPLed program is on the same level as any other player?
And how can you write a lengthy article on these topics without even mentioning what is probably the biggest issue to free software: it is not some "bait and switch" where open source projects get relicensed. It's that much software people use is now a service. The user has no control whatsoever; they are not even getting to install a binary executable on their own machine. The licensing is irrelevant to the end user.
This entire article is about the bickering among developers: who gets what kinds of rights to which infrastructural pieces, with it being understood that everyone's shared goal is cobbing something together with those pieces in order to hold hostage the hapless users of some god forsaken SaaS application.
OK, so sure; if we put developer blinders on, open source is the default. My compiler is open source; my editor is open source; the OS is open source; the browser is open source; the database is open source. Hey open source is the default!
Meanwhile, Average Joe: social network isn't open source; webmail isn't open source; crap running in Joe's automobile isn't open source; Joe's phone isn't open source; Joe's TV streaming box isn't open source. Neither are the half dozen apps Joe relies on for this and that, or services like online banking. Almost not a single everyday use case or solution for the average user is open source. How can you talk about a default with a straight face. And this is just the consumer-facing stuff I'm talking about. For instance, let's switch to business. What enterprise runs their finances, operations and logistics on open source?
This article consists of a few highly selective observations, glued together by make-believe.
Open source was the industry default? On what planet?
"Team, make everything open source by default, unless I tell you otherwise" --- said no CEO or other boss, ever.
We have a lot of open source; a lot of it is very advanced, and forms critical infrastructure, sure. But proprietary software has not gone away even slightly.
I disagree with this assertion. Twenty years ago, the average enterprise developer was mostly using proprietary software. Examples: Browser (e.g. IE), IDE (e.g. Borland), OS (e.g. Windows), application server (e.g. WebLogic), DB (e.g. Oracle), CMS (e.g. Vignette), etc.
Today, the enterprise stack is dominated instead by OSS options: Browser (e.g. Chrome), IDE (e.g. Eclipse - VS Code is mostly open source, but includes proprietary elements), OS (e.g. Linux), application layer (e.g. Kubernetes), DB (e.g. Postgres), CMS (e.g. Drupal/Gatsby/WordPress), etc. Which is not to mention the thousands of underappreciated open source dependencies that applications rely on.
Proprietary software has certainly not gone away, and will not depart any time soon. But the implicit claim that nothing has changed in the balance of power between open source is not supported by the available evidence.
> Open source licenses, after all, offer the same equitable terms to all players, and limit neither competition nor usage.
Really? The sole proprietor of some GPLed program is on the same level as any other player?
In terms of their rights to and responsibilities for the source code? Yes. This is the express and intent and purpose of copyleft licenses. Knowledge of the source code may be asymmetric; the rights to it are not.
And how can you write a lengthy article on these topics without even mentioning what is probably the biggest issue to free software: it is not some "bait and switch" where open source projects get relicensed. It's that much software people use is now a service. The user has no control whatsoever; they are not even getting to install a binary executable on their own machine. The licensing is irrelevant to the end user.
Because this particular piece is about relicensing. There are other pieces about the topic you mention. This one from six years ago, for example, discusses the threat posed by the cloud to OSS software (https://redmonk.com/sogrady/2016/06/02/future-of-open-source...).
This entire article is about the bickering among developers: who gets what kinds of rights to which infrastructural pieces, with it being understood that everyone's shared goal is cobbing something together with those pieces in order to hold hostage the hapless users of some god forsaken SaaS application.
I'd argue that it's less about bickering between developers than the reality that commercial entities are using OSS licenses to grow their project traction, and once a critical mass is achieved, pulling the rug out from under developers with a non-open source license with more restrictive terms.
OK, so sure; if we put developer blinders on, open source is the default. My compiler is open source; my editor is open source; the OS is open source; the browser is open source; the database is open source. Hey open source is the default!
Precisely.
But don't forget the front end framework (e.g. React). The static site generator (e.g. Hugo). The testing framework (e.g. Playwright). The software catalog and developer portal (e.g. Backstage). And so on.
Meanwhile, Average Joe: social network isn't open source; webmail isn't open source; crap running in Joe's automobile isn't open source; Joe's phone isn't open source; Joe's TV streaming box isn't open source. Neither are the half dozen apps Joe relies on for this and that, or services like online banking. Almost not a single everyday use case or solution for the average user is open source. How can you talk about a default with a straight face. And this is just the consumer-facing stuff I'm talking about. For instance, let's switch to business. What enterprise runs their finances, operations and logistics on open source?
Average Joe generally isn't building a social network, a webmail offering, a car, a phone, or a streaming TV service.
Average Joe, in most case, just wants, say, a database. The easiest of which to acquire used to be open source but these days is as likely as not to have transitioned to proprietary software.
Which is not ideal.
"Team, make everything open source by default, unless I tell you otherwise" --- said no CEO or other boss, ever.
We have a lot of open source; a lot of it is very advanced, and forms critical infrastructure, sure. But proprietary software has not gone away even slightly.
I disagree with this assertion. Twenty years ago, the average enterprise developer was mostly using proprietary software. Examples: Browser (e.g. IE), IDE (e.g. Borland), OS (e.g. Windows), application server (e.g. WebLogic), DB (e.g. Oracle), CMS (e.g. Vignette), etc.
Today, the enterprise stack is dominated instead by OSS options: Browser (e.g. Chrome), IDE (e.g. Eclipse - VS Code is mostly open source, but includes proprietary elements), OS (e.g. Linux), application layer (e.g. Kubernetes), DB (e.g. Postgres), CMS (e.g. Drupal/Gatsby/WordPress), etc. Which is not to mention the thousands of underappreciated open source dependencies that applications rely on.
Proprietary software has certainly not gone away, and will not depart any time soon. But the implicit claim that nothing has changed in the balance of power between open source is not supported by the available evidence.
> Open source licenses, after all, offer the same equitable terms to all players, and limit neither competition nor usage.
Really? The sole proprietor of some GPLed program is on the same level as any other player?
In terms of their rights to and responsibilities for the source code? Yes. This is the express and intent and purpose of copyleft licenses. Knowledge of the source code may be asymmetric; the rights to it are not.
And how can you write a lengthy article on these topics without even mentioning what is probably the biggest issue to free software: it is not some "bait and switch" where open source projects get relicensed. It's that much software people use is now a service. The user has no control whatsoever; they are not even getting to install a binary executable on their own machine. The licensing is irrelevant to the end user.
Because this particular piece is about relicensing. There are other pieces about the topic you mention. This one from six years ago, for example, discusses the threat posed by the cloud to OSS software (https://redmonk.com/sogrady/2016/06/02/future-of-open-source...).
This entire article is about the bickering among developers: who gets what kinds of rights to which infrastructural pieces, with it being understood that everyone's shared goal is cobbing something together with those pieces in order to hold hostage the hapless users of some god forsaken SaaS application.
I'd argue that it's less about bickering between developers than the reality that commercial entities are using OSS licenses to grow their project traction, and once a critical mass is achieved, pulling the rug out from under developers with a non-open source license with more restrictive terms.
OK, so sure; if we put developer blinders on, open source is the default. My compiler is open source; my editor is open source; the OS is open source; the browser is open source; the database is open source. Hey open source is the default!
Precisely.
But don't forget the front end framework (e.g. React). The static site generator (e.g. Hugo). The testing framework (e.g. Playwright). The software catalog and developer portal (e.g. Backstage). And so on.
Meanwhile, Average Joe: social network isn't open source; webmail isn't open source; crap running in Joe's automobile isn't open source; Joe's phone isn't open source; Joe's TV streaming box isn't open source. Neither are the half dozen apps Joe relies on for this and that, or services like online banking. Almost not a single everyday use case or solution for the average user is open source. How can you talk about a default with a straight face. And this is just the consumer-facing stuff I'm talking about. For instance, let's switch to business. What enterprise runs their finances, operations and logistics on open source?
Average Joe generally isn't building a social network, a webmail offering, a car, a phone, or a streaming TV service.
Average Joe, in most case, just wants, say, a database. The easiest of which to acquire used to be open source but these days is as likely as not to have transitioned to proprietary software.
Which is not ideal.
Is this a covert hit piece against licenses that prevent the very same "investors" from exploiting opensource by SaaS?
If you're referring to licenses that - at times intentionally - blur the definition between open source and proprietary, yes. It is not in favor of those licenses.
The implicit argument that these licenses singularly benefit SaaS is much more nuanced than is implied above, however, in that some licenses actively discourage SaaS (e.g. AGPL) and other open source projects (e.g. Postgres) have actively benefitted from SaaS (or more accurately DBaaS).
The implicit argument that these licenses singularly benefit SaaS is much more nuanced than is implied above, however, in that some licenses actively discourage SaaS (e.g. AGPL) and other open source projects (e.g. Postgres) have actively benefitted from SaaS (or more accurately DBaaS).
Is there a FOSS license specifying royalties?
Or maybe dual licensing? FOSS for all "end user" customers. Royalties (or equiv) for non end users repackaging the FOSS as a service.
Back in the day, for commercial stuff, we'd license libraries and such. Some had royalties, or were otherwise based on usage.
Or maybe dual licensing? FOSS for all "end user" customers. Royalties (or equiv) for non end users repackaging the FOSS as a service.
Back in the day, for commercial stuff, we'd license libraries and such. Some had royalties, or were otherwise based on usage.
There is misunderstanding of profits and software vs. hardware.
During the early computer era, the most difficult and expensive problems to solve were in hardware. The profits flowed there.
In recent years, compute was cheap compared to the value provided by quality software - and the software could run on a variety of hardware systems. So software captured most of the value.
There are some new problems that are difficult and expensive to solve that must be solved in hardware. This is making investment and profits flow back to hardware makers. Furthermore the years of commoditization of hardware resulted in consolidation and survival-mode until there were only a handful of serious players in various layers of the manufacturing stack. This will get resolved but will take a long time (decades).
AI businesses constantly need to improve and retrain models. This is extremely compute intensive and time consuming. Therefore we need hardware that is optimized to this specific type of number crunching. This hardware is novel and needs smart and talented people (therefore investment).
As an investor (both of capital and of your labor) you need to analyze where the expensive problems are, with the highest need to be solved, with those that need it most having the highest ability to pay. If you optimize on that spectrum your investment has a better chance of success.
Computer people are drawn to nostalgia, especially considering the entire history of our craft has been meticulously recorded by enthusiasts. We get drawn to certain types of problems and environments and every 10 years the entire world changes. Our profession is one of constant disruption and change.
What makes me rest easy is that the fundamentals have remained constant since the earliest theoreticians. We must use the best algorithms to reduce compute as much as possible. If you do that you win, at the most fundamental level. It’s another way of saying that you must solve the problem as simply as possible (and no simpler).
As an addendum, I don’t fault any talented and ambitious person who goes into the industry where they can make the most money as fast as possible. Some people lament that the best and brightest don’t go into, say, NASA or public school teaching or some such sacrificial act. The bursting of the tech bubble in 2022 and the drying up of VC capital to dime-a-dozen nonsense startups will help drive talented people back to hard problems.
During the early computer era, the most difficult and expensive problems to solve were in hardware. The profits flowed there.
In recent years, compute was cheap compared to the value provided by quality software - and the software could run on a variety of hardware systems. So software captured most of the value.
There are some new problems that are difficult and expensive to solve that must be solved in hardware. This is making investment and profits flow back to hardware makers. Furthermore the years of commoditization of hardware resulted in consolidation and survival-mode until there were only a handful of serious players in various layers of the manufacturing stack. This will get resolved but will take a long time (decades).
AI businesses constantly need to improve and retrain models. This is extremely compute intensive and time consuming. Therefore we need hardware that is optimized to this specific type of number crunching. This hardware is novel and needs smart and talented people (therefore investment).
As an investor (both of capital and of your labor) you need to analyze where the expensive problems are, with the highest need to be solved, with those that need it most having the highest ability to pay. If you optimize on that spectrum your investment has a better chance of success.
Computer people are drawn to nostalgia, especially considering the entire history of our craft has been meticulously recorded by enthusiasts. We get drawn to certain types of problems and environments and every 10 years the entire world changes. Our profession is one of constant disruption and change.
What makes me rest easy is that the fundamentals have remained constant since the earliest theoreticians. We must use the best algorithms to reduce compute as much as possible. If you do that you win, at the most fundamental level. It’s another way of saying that you must solve the problem as simply as possible (and no simpler).
As an addendum, I don’t fault any talented and ambitious person who goes into the industry where they can make the most money as fast as possible. Some people lament that the best and brightest don’t go into, say, NASA or public school teaching or some such sacrificial act. The bursting of the tech bubble in 2022 and the drying up of VC capital to dime-a-dozen nonsense startups will help drive talented people back to hard problems.
Hacking society and extracting value will always be more profitable and prestige loaded within the group of smart people as long as it is not shunned culturally.
The "top that" nature of intellectual exploits and society measuring success in monetary output (even though that value shrinks when the physical reference frame shrinks) makes the culture of HN and Wallstreet are a obsticle to scientific progress. Optimization for minimal effort maximum output of intellectual archievements, traps humanity on a local maximum.
My house, my car, my boat at every grill party will prevent grill partys from continuing because nobody gets a big house, big car, big boat by farming.
Now if only we had a stereo type, displaying monetary rentseeking as a despicable endavour, we could go full circle and get on with it.
The "top that" nature of intellectual exploits and society measuring success in monetary output (even though that value shrinks when the physical reference frame shrinks) makes the culture of HN and Wallstreet are a obsticle to scientific progress. Optimization for minimal effort maximum output of intellectual archievements, traps humanity on a local maximum.
My house, my car, my boat at every grill party will prevent grill partys from continuing because nobody gets a big house, big car, big boat by farming.
Now if only we had a stereo type, displaying monetary rentseeking as a despicable endavour, we could go full circle and get on with it.
Companies who generate billions in revenue using open source products while refusing to contribute financially to their ongoing viability are the primary motivating factor.
You have bills to pay and you want to do what you love doing and they don’t care about that, so you explore your options as the copyright holder.
Investor greed came after that. Ditto for “kids today take it for granted”.