(Disclosure: I'm from Digger and OpenTF so am biased)
Hashi's biggest miscalculation is that they put Terraform (an open language / ecosystem) into the same bucket as Vault and Consul, which are hostable backend applications.
BSL makes sense for Vault, just like it does for MongoDB. It is reasonable to prevent others from charging for hosting your code.
But with Terraform, the backend part (TF Cloud) was never even open source. And it's not required for Terraform to work.
Hashi shot themselves in the foot. Unlike with Vault or Consul, there is enormous vested interest in the community to keep Terraform truly open. Hashi trying to enforce everyone to use their non-oss backend with it will only result in Hashi losing the privileged (and well deserved) position among providers of commercial products in the Terraform ecosystem.
It's a repeat of what Elasticsearch did to their community. Basically, their product got forked (Opensearch) and the fork is now popular. Result: access denied on a sizable percentage of new users that start off using the fork and will likely never transition to the closed source thing.
As a sales strategy it's dumb. I see this as an Elasticsearch/Opensearch consultant. A lot of people reaching out to me for help with that, seem to now default to starting with opensource, i.e. Opensearch. And since a lot of them are in Amazon (who created the fork) they make that really easy. Those are people who will likely never become Elastic customers.
The same will happen with Teraform. Many new users will default to the open fork. A lot of existing users might migrate to that.
There are some other examples:
- Oracle lost control of Hudson when it became Jenkins. Hudson is now a footnote in history.
- Likewise with OpenOffice, which now rots away at the Apache Foundation. LibreOffice is the main product now.
> It's a repeat of what Elasticsearch did to their community.
Not exactly the same as I understand. Amazon were providing Elasticsearch as a service with nothing in return. Fair enough. Although there did seem to be some issues about alleged ripping off code and trademark infringement.
However as Elasticsearch needed to remain a viable business, they changed the licence.
Architecturally, I think Terraform really ought to be hosted, because otherwise you have to trust everyone with a far-reaching admin cred on his desktop right next to Zoom and maybe BonziBuddy.
That's tricky since the state file frequently contains secrets. You can try to keep secrets out of the state file but that's largely provider/resource dependent. For instance, if you create an AWS RDS Postgres database, the state ends up containing the resource password. If you allow only plans, users can still access the password in the state file.
For RDS you can change the password after creating the DB, or use the SecretsManager integration.
There are similar workarounds for other providers and resources. I use TF without storing secrets in the state file (providers: AWS, kubernetes, helm, onepassword, datadog, auth0, and more).
You can exfiltrate secrets that aren't in the state, but are in accessible resources during a plan using an http data source with the secret encoded into the url
stuff like Atlantis exists. it doesn’t eliminate the need for someone/something to have wide permissions, but you definitely can narrow who/what has that access day to day.
Same issue. Terraform doesn't separate invoker permissions from runtime permissions. It runs with whatever privileges the invoker provides and since it's doing arbitrary privileged things it generally runs with arbitrary privileges.
The only real fix is to run it in a client-server model like a web app where the user has limited permissions and the server gates access to the privileged backend permissions.
Put another way, if I want to create an S3 bucket on AWS, I need S3 CreateBucket privileges, not "run Terraform" privileges.
this is a great point. I've been following your work decently closely but this is the first time I thought about the "hostable" vs "non-hostable" differentiation. And thinking more deeply on it, of course it matters. There's a pretty big distinction and, naively, perhaps their attempt to protect TF Cloud with this doesn't even accomplish what they intended for it to accomplish. If the backend part is the thing...that was never even in contention, anyway. If this is the case, they only managed to hurt the community.
I didn't know that any serious non-Hashicorp backends for Terraform existed before this scandal and I wouldn't have considered anything other than Terraform Cloud. The scandal has soured me on Hashicorp and made me aware of the alternatives. I doubt I'm the only one.
If you are on AWS, there is little reason not to use the S3 backend. If Hashicorp insisted on using their backend only, they would be as popular as Pulumi now (which will be another player to gain from this battle).
This is probably going to get a lot flake but what did we expect when big tech started eating up open source solutions and competing with the companies who started the work . MongoDB and AWS is a good example. Hashicorp probably realised that they should preemptively change the licensing before bigger players started using the products to directly compete with them.
I want Hashicorp to survive and be profitable. Fact is, for the majority of the users who use terraform, the change in licensing does not impact them.
True...it's just difficult to draft a license that says something along the lines of "If you're Big Tech, we have the right to go after you, if you're small startup, you're safe".
I think there's a swath of Terraform users (likely minority) who find themselves in a legal gray area, or a legal black-and-white area, where they're directly at risk. Even if Hashicorp never intended to target small startups with this, the wording of the license unfortunately applies and is enough to make anyone nervous.
I think MongoDB had a similar issue when they went source-available, they seemed to intend to only protect themselves from big tech but unfortunately a lot of smaller players got spooked. I think (?) it's fine now though
I don't know if it'd really be hard (you could list them, or have various limits on users or total revenue among all related companies). You could broadly include all subsidiaries, contractors working for Amazon, companies effectively under their control, etc. (Ultimately it'll be interpreted by a judge, not an algorithm, that probably makes it harder to get around.) There is nothing illegal about offering a license to everyone except Amazon, Microsoft, and Google.
But none of those licenses would be open source licenses. That's the problem with doing it — you can't do that in an open source license.
The no discrimination clauses are a requirement of the open source definition, not the law. (The law of course does have some non-discrimination requirements, not sure how many of those apply to copyright licenses. But none of the normal ones would prohibit "everyone but Amazon may use this".)
> True...it's just difficult to draft a license that says something along the lines of "If you're Big Tech, we have the right to go after you, if you're small startup, you're safe".
Take a look at the license of LLAMA2 by FB. It has a clause just like this. I.e. limit by number of users.
wow, didn't know about this. very cool + would be interesting to see this in more places. Just checked it out. for those lazy:
"If, on the Llama 2 version release date, the
monthly active users of the products or services made available by or for Licensee,
or Licensee's affiliates, is greater than 700 million monthly active users in the
preceding calendar month, you must request a license from Meta, which Meta may
grant to you in its sole discretion, and you are not authorized to exercise any of the
rights under this Agreement unless or until Meta otherwise expressly grants you
such rights."
yea, that makes all the difference. If it was almost all Hashicorp, the open source was a marketing gimmick and I don't blame them for not risking the entire business on it. If there was heavy involvement from external contributors, then removing open source is more of a rug pull.
> This is probably going to get a lot flake but what did we expect when big tech started eating up open source solutions and competing with the companies who started the work
Big tech started doing that when open source as fairly young, and it was never a problem, because no one was launching a business centered around making open source software and being better than big established firms at selling services around it.
What actually created the crisis is when, a couple decades later, people started to launch VC backed startups with the growth demands that involves and business plans that centered around creating open source software and selling hosted access to it.
Even for VC backed startups, I think it was never a problem until cloud providers started competing with them. It is not a level playing field if your competitors are big players like Amazon who can take away a lot of your possible customers.
> Even for VC backed startups, I think it was never a problem until cloud providers started competing with them.
Cloud providers (and SaaS providers before the dynamic provisioning for which “cloud” was coined existed) have been offering commercial hosted OSS solutions since before there were VC-backed “our whole business model is developing OSS and selling hosted access to it” startups.
The thing that changes was the startups trying to trade on OSS' cultural impact with a business model that made no sense, not the practices of cloud providers.
Fair enough, but it was never a problem because most software like Terraform would not have been open source to begin with in the good old days. So in a way yes, what you said is true, but I don't think the takeaway is "open source used to work just fine", but rather "sometimes a non-open-source license is really what works in this scenario".
AGPL doesn't address the issue that is driving many of these license changes.
The problem they are trying to deal with is that they have some product that is useful on servers that they have released under a license like Apache or GPL, and they make their money by selling hosting and support, and big hosting companies like AWS start including the product for free as part of their own hosting offerings or start selling support.
AGPL would only discourage that if the big hosting company wanted to make modifications to the project and keep those private. But the threat to the project is not that say AWS is going to make a better version of the product. It is that they are going to make it more convenient and cheap for their hosting customers. They will either not need to make any changes for that, or the changes they make would probably not be useful to anyone else and releasing them won't bother them.
Look at MongoDB. That was under AGPL for several years and they switched away because it was not stopping cloud providers from competing with them on MongoDB hosting.
It's not just big tech that hates AGPL. If Terraform was under AGPL a lot of companies might have to release their source code as AGPL too because of its virality. Where it stops is not exactly clear from the license.
AGPL is almost exactly the same as GPL except that SAAS counts as distribution. That's the entire purpose of the license — to preserve the copyleft protections of the GPL in a world where most software people use is hosted.
Except it’s not just hosting the covered work itself as SAAS that triggers a distribution, but any derived work. If you use (say) AGPL MongoDB in your SAAS bug tracker, your bug tracker now needs to be AGPL too. The virality doesn’t stop at hosting a SAAS MongoDB.
That's probably not correct. While the AGPL is a little ambiguous, it probably does not infect other apps. That's why I created the Candid Public License (CPL): https://github.com/candiddev/cpl
Every lawyer I’ve talked to takes my interpretation. It may be overly cautious of them, but in practice, if something becomes the prevailing legal view, it de facto is the correct interpretation, at least until it is tested in court.
Recall that the GPL (non-affero) categorizes runtime linking to GPL’d binaries as a derived work. (This is why the LGPL exists, to allow for what the regular GPL restricts.)
The logic of the lawyers I’ve talked to (2 different companies on multiple occasions with different lawyers) is that the same wording that causes network access to count as “distribution” in the AGPL, also causes networked API access to count as a derived work.
It’s not all that crazy of an interpretation, IMO. My lawyers may suck and be overly cautious, but I’d wager this uncertainty is exactly why any sane company stays as far away as possible.
> Recall that the GPL (non-affero) categorizes runtime linking to GPL’d binaries as a derived work
If its not a derived work under copyright law requiring a license, a license offer can’t transform it into a derived work requiring a copyright license.
So, thought experiment: say I do want to take AGPL MongoDB, alter its source code, and host my modifications as a SAAS without releasing my modifications, and get away with it.
One way I could do this is by completely implementing its wire-format API of MongoDB as a proxy server to my derived MongoDB, and offer that up as my SAAS.
I could use a defense that I’m not distributing MongoDB, I’m distributing my proxy service I wrote myself. It just happens to be that my proxy service talks to MongoDB to do its job, but according to you that’s not a derived work, because network access doesn’t count.
For AGPL to still protect MongoDB in this scenario, the proxy-plus-mongoDB combo would have to count as the derived work, and I think the only way to do this is to count any API access as deriving a work. I think this is at least how the lawyers I’ve talked to described it.
GPL has already established that runtime linking counts as a derived work. If what you’re saying is true about “not a derived work under copyright law requiring a license”, then I don’t understand why the LGPL exists.
GPL's source disclosure requirements trigger on distribution.
AGPL's trigger on distribution or on allowing remote user interaction over a computer network.
> I could use a defense that I’m not distributing MongoDB, I’m distributing my proxy service I wrote myself
You aren't distributing either of them. When you run code on your server and people interact with it over the network that's not a distribution. If it was a distribution there would be no need for AGPL. GPL would be sufficient.
> It just happens to be that my proxy service talks to MongoDB to do its job, but according to you that’s not a derived work, because network access doesn’t count.
It's not a derivative work because it doesn't incorporate copyrighted elements of MongoDB (assuming you didn't actually copy code from MongoDB).
> For AGPL to still protect MongoDB in this scenario, the proxy-plus-mongoDB combo would have to count as the derived work, and I think the only way to do this is to count any API access as deriving a work.
AGPL would protect MongoDB in that scenario because you are allowing remote users to interact with MongoDB over a computer network. That this interaction happens to be taking place through a proxy shouldn't be relevant.
> You aren't distributing either of them. When you run code on your server and people interact with it over the network that's not a distribution. If it was a distribution there would be no need for AGPL. GPL would be sufficient.
I think you’re misreading this part of my comment: MongoDB is (or at least, was) AGPL, and AGPL defines network access as distribution. So I would have to justify whether offering my proxy service to network access counts as distributing MongoDB, or if laundering it through a proxy works around this. Remember that in my example, I did modify mongoDB. But I’m not technically offering this modified mongoDB as a service, I’m offering my proxy as a service, and hoping that it doesn’t count as “distribution” of my modified mongoDB. (i.e. I’m not distributing mongo, I’m distributing my proxy, and my proxy is not AGPL.)
> AGPL would protect MongoDB in that scenario because you are allowing remote users to interact with MongoDB over a computer network. That this interaction happens to be taking place through a proxy shouldn't be relevant.
Well, that’s the thought experiment that my example is intended to provoke… it seems obvious that my dumb proxy is a way to work around the AGPL, but what if we tweak the example? What if I make a web UI where you type mongo commands and it gives you the result? (Still pretty obvious, no?) What if I make a simple dumb CRUD app that happens to use MongoDB? (Less obvious…) what if the CRUD app is itself an extremely thin wrapper, and although it doesn’t implement any MongoDB protocols, it leverages built-in mongoDB functionality for 99% of the logic?
The point is, it’s not hard to imagine a legal theory that says “if network access equals distribution, then network access equals a derived/combined work”. It’s the theory that the legal departments of several companies I’ve worked for have taken. And I’d argue that if you have a proprietary product that uses an AGPL service as part of the backend, you have a rather large reason to be worried.
By my reading, the AGPL doesn't define "distribution" at all. It defines "conveying":
To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying
This definition specifically excludes networked API access.
Here's what the AGPL says about network access:
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
It only applies if you "modify" the program. Does creating a proxy service count as modifying the original program? I think it could count as a derived work, but I would be very surprised if that counts as a modification.
Doesn't it prove GP's point? If you use MongoDB in your commercial software it gets infected with AGPL, because people interact with it over the internet - just like linking does with GPL.
> GPL has already established that runtime linking counts as a derived work
No, whether runtime/dynamic linking (or even static linking) creates a derivative work under copyright (as is when, to the extent it does, such a use would nonetheless be fair use and still not require a license) is still a contentious topic, and AFAIK there are no cases strongly suggesting a general answer.
A license offering permission cannot itself resolve when the law requires such permission. Arguing that it can is like saying my offering terms of permission to use my home and claiming that they apply to use of the public street out front establishes that I own the street.
If your argument is that AGPL can’t restrict me from using mongo in a proprietary product because copyright law itself does not restrict this, then you may or may not be right, I don’t think any of us know for sure until this is tested in court. I will say that the AGPL is written with the assumption that this is restricted by copyright law, so I don’t think your interpretation is the common one.
> One way I could do this is by completely implementing its wire-format API of MongoDB as a proxy server to my derived MongoDB, and offer that up as my SAAS
This is what Cosmos DB for Mongo DB is (wire format endpoint that talks to Msft’s own DB backend.)
The AGPL says "including scripts to control those activities" but if I understand what you are saying properly it means that the text of the AGPL is overreaching and some parts of it wouldn't be applicable?
Would the details depend on the country? Like it might be one thing under US law, and another in another country?
If the AGPL defines network access as distribution, it stands to reason that network access also counts as linking. See my other comments about a hypothetical proxy that thinly wraps mongoDB as an AGPL workaround, for why this gets hairy very quickly.
AGPL does not add any distribution clause... all distribution clauses are taken from the GPL...
The AGPL adds a modification clause so that if you ever modify the code even if you do not distribute the application, you still have to share the code or at least link to the version of the source code that you use. The loophole that AGPL fixes is that there are ways to avoid distribution.
This AGPL/GPL virality urban legend should have ended years ago.
There is no such thing as "virality". It doesn't exist. The worst thing you can do is violate the license terms and not be allowed to use the software that is AGPL licensed.
And yet everyone understands what this term means when applied to software licensing. Pretty good argument that this word, in fact, exists and has a well defined meaning.
Not really. The lawyer Kyle Mitchell said of the agpl,“Inebriated aliens might as well have beamed it down from space as a kind of practical joke.” Even lawyers have trouble understanding when its provisions are triggered.
The AGPL defines "Corresponding Source" as "all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities".
Then in section 13 it says that "your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge".
Isn't "scripts to control those activities quite vague? Under those terms wouldn't AWS Proton, IBM Schematics, Env0, Digger, Spacelift, etc. be required to open-source a very large part of their product as well?
I think, if Terraform was licensed under AGPL, then not only would all of those folks would have to also open-source their products, but also that would be the intent of the license in the first place
offtopic, but it's "getting a lot of flak". As in "heavily being fired on by German anti-air guns" (called FlaK, short for Flugabwehrkanone, literally anti-aircraft cannon)
I am working for a Big Corp. I have see many instances where we made expensive contracts with small companies maintaining open source solutions. It fits existing processes and we have somebody who will fix stuff. Most of the time, it would be much more expensive to keep a team to maintain the software ourselves.
If they started out openly proprietary, they wouldn't have got the same level of contributions from people outside the organisation, and wouldn't have reached the current popularity.
Hashicorp did it the right way round. Open source, friendly, rug pull, profit, obsolete, forgotten.
One thing that I've been curious to see, and not sure if anyone has done it yet, is a quantification of contribution to Terraform, comparing amount of work done from external contributors to the work done by Hashicorp-internal contributors.
I know it's hard to make the comparison of what is "harder" work or "more" work in a software project from looking at commits alone, but would be interesting to see nonetheless.
It's not just the work donated via the open source channel, it's also the associated credibility, enthusiastic coverage and referrals, and general good will, that accrues to such a project. None of which they would have enjoyed had they been a private project.
definitely...and they get to keep that credibility and coverage. at least, as long as this move didn't totally alienate the folks that got on terraform back then
That credibility largely only applies to a certain group of people. The license change tanked that credibility with that group of people. Hashicorp did a classic misstep for open source based companies and as a may have lost the mindshare and marketshare for one of their most significant offerings. I'm actually not sure they'll survive this.
> The license change tanked that credibility with that group of people
tho a separate group of people who actually decide the finances of companies will not be in this same group. As old saying goes, "Nobody Gets Fired For Buying IBM".
When a senior engineer comes to that person and says. You can stop paying hashicorp money. We found a free alternative and are no longer using their product. That person will happily and joyfully jettison the contract. I've been that senior engineer before and the CTO and CFO have never pushed back on the idea that they don't have to spend any more money. Especially now when cutting costs is a concern everyone is being forced to care about.
Make your code open-source, but don't merge in PRs, don't actually use it for development, and don't promise anything buildable. (NetApp, Tesla, Samsung do this)
OR have the core of your tool be open-source but add proprietary value on top of it so that the proprietary version is more attractive (like Tailscale with their Coordination Server). With Terraform, this could have been the cores that manage plans and state.
The issue here (purely unsubstantiated outsider opinion) is that Mitchell is a hacker that created things that were immensely valuable and punted the profit part of it for later. Hard to undo that, but it was good enough to raise millions on millions and create a super sweet company to work for (before they went public and were forced to wear a suit like the rest of The Street)
Yeah, so Tesla AFAIU isn't even GPL compliant as what they publish is not the complete corresponding source code for their Linux/buildroot based firmware.
Salami slicing tactics are pretty common, that way you can gaslight detractors by saying they’re crazy for making a fuss over such insignificant changes.
1. The elephant in the room here is VCs that pushed unsustainable pure open source or open core business models during ZIRP. You can't do it right from day one if your investors are pushing you the opposite direction.
2. People keep talking about community contributions but hasn't Hashicorp rejected all contributions for years?
On 2), you can define contributions narrowly as PRs in the repo, or broadly, as building providers, libraries, and documentation in the ecosystem. I think the latter perhaps makes more sense.
Contributing providers, for example, is a massive contribution of labor that Hashi would have had to do themselves if the community didn’t.
didn't think about the documentation but that's especially true...it's a massive amount of copy, between all the tutorials, how-tos, educational material, and example code, all mindfully presented in a useful way
would love to know a definitive/quantitative answer for #2, for sure. I do think it makes a difference when it comes to the "backstabbing" implications of the change
this is a great point...further down the comments, an OpenTF maintainer made a great point that all of these services are "backend hostable" services. Terraform doesn't even have a backend service component...Terraform Cloud does, but not Terraform itself.
I didn't contemplate this when writing the article but it seems like this might be a pretty big factor in the reaction to the change. At least to my memory, I don't remember as strong as a pushback from any of these companies changing their licenses
ah wow...I guess that begs the question, "will this just blow over". As far as I can tell Elasticsearch continues to do well and is more or less in the clear (could be wrong)
> if you want to start a business building developer tooling and you’re concerned about competitors using your work, you should probably start source-available (BSL) and then go for a license that is OSI-approved
To put another way, if you want to start a business, make sure what you're selling you can do better than others. If your business is hosting open source software and you can't do that better than others, then don't make that your business. Maybe you should have been selling non-open-source instead (which they pivoted to now anyways).
My take is that if I want to run a business on open source, I license as AGPL3 with asterisk.
Asterisk: if you want a permissive license, our salespeople are _right around the corner_, and they will take you to a steak dinner with our professional services lead, and you will have a fantastic white glove onboarding, and it will be absolutely lovely for everyone's bottom line.
One is best not to make any decisions on how something will be in the future. This goes for pre ordering games, to buying software licenses, to opensource contributions.
People contributed to the software as it was licensed then, and this software is still available under the open source license and can’t be taken away. Unfortunately that gives no guarantees about future versions or versions that never got made.
100% agreed with you...would be safest for everyone to take this stance going forward. I do think, and I could be wrong, that not everyone realized that the licensing worked this way. Or had their guard up when contributing. I think that's the issue...perhaps their fault, perhaps not, but I see the issue.
I wonder if this will be an example moving forward that people keep in mind when contributing to any OSS project
Doesn't this mean that people will be more cautious and less likely to contribute on the long run? I mean that feels like it is against the spirit of open source movement. And yes I realize that this is idealistic position and the legal aspects gets the upper hand at the end. I just wish things didn't go this way.
I imagine so...I wonder if its possible to draft an open-source license that commits future versions of the project to be drafted under the same license. Maybe AGPL does this (?) I know AGPL applies to all "modifications", I wonder if that applies to modifications done by the maintainers themselves in the future. If so, maybe we'll see AGPL-like provisions becoming more popular in order to help folks feel more confident
With terraform “keeping up with the latest” is way more important than say regular libraries and tools like ReactJS.
A 5 year old react would mostly work fine (patch the odd bug if need be). Indeed look at Elm. But terraform is coupled to the moving target of cloud services.
I think I get the point of your comment but can you expand? For instance, I’ve resorted to pinning a specific terraform version and plug-in version in a custom docker container. I can use the same TF scripts I wrote 4 years ago against the AWS API which has not changed since.
Yes I think your case is OK. The question is more say your team decides to use a new feature, let's say it is GPT5 via Azure for example, with TF. Then you need to keep up to date. I am not heavily into TF so I don't know if that is possible with the pinned terraform and using later providers versions or how that works. But it seems more hassle than just using the latest of everything.
Note I am talking about "keeping up" as a general need for IaC - but it might turn out that the TF fork is a better place to do that in the long term. Time will tell.
I chased TF version updates for a while before being annoyed at having to retool significant parts of my long existing scripts. I gave up and just stuck to a version for what I needed. My only concerns is I may neglect a security update, but this is for personal stuff and not for anything that others use/consume.
No, they go public because they need more funding. They need more funding because they're not profitable. The reason 100% is because they didn't build a profitable business out of open source, so they have to change it to try to build something sustainable once opportunities for funding run out.
Most of you guys are missing the forest for the trees. HashiCorp has been around for over a decade now and they've never turned a profit. ZIRP is over.
If you guys keep sending these companies to the graveyard, there will no longer be an incentive to fund them. Then OSS will be reduced down to projects incubated by FAANG or stuff created by hobbyists.
Imagine you are a capital allocator, why would you burn your (LPs) money for what amounts to free R&D for MSFT/GOOGL/AMZN.
If you are going trash a company for taking the only viable path to maintain its existence, at the very least provide a feasible alternative.
The thing is its not the 90s anymore, pretending otherwise is how you get LibreOffice or Inkscape.
Tech has come a long way since the creation of linux or python. Even these projects have gotten to a level of sophistication that it would implode without big tech support.
Why do you think you don't see any interesting oss tech from hobbyists is these days? All the ones you see are either incubated inside FAANG or VC backed.
To build, grow and maintain anything thats interesting these days will require a group of pretty talented people and these people have plenty of other prospects where they'll get paid pretty well.
Let say you have a cool pretty printing library on one end and on the other end you had a new kind of in memory data store that is an order of magnitude better in performance and efficiency while providing exceptional horizontal scaling.
What I'm getting at with "interesting" are projects that look more like the latter.
There are plenty of exceptions where you have projects that fits (barely) into the interesting category while staying just below the complexity threshold that it can be maintained by one guy and a few community contributions.
Yet they are still the exception to the rule and even then you often have one of the following outcomes:
- The features or the project as a whole get stolen/integrated by FAANG, hobbyist burns out and hobbyist ends up depreciating/archiving the project.
- The project gains a lot of momentum and gets supported by FAANG.
- Hobbyist burns out and depreciates/archives the project
- Hobbyist commercialises the project.
P.S.
Entropy is a ditch and this is what many of the HN utopians fail to understand, it takes a immense amount of work to build a somewhat self-sustaining entity to fend of entropy. I have theory that its one of the blindspots of being young and technical. You see the world as a massive legacy monolith that you have to refactor into these cool edgy microservices which is super easy and all the problems will be solved and happily ever after. While I don't disagree with parts of the original claim, the solution IMO will end modern civilisation as we know it. I have a bunch of labels for this kind of thinking and the people who preach it but I know señor dang wont be happy about it so I digress..
1) FAANGs won't exist forever, software/hardware development will continue even after FAANGS will be disassembled by antitrust, go in bankruptcy or stop investing for any other cause.
2) Linux and a lot of other complex software was developed when collaboration was not so easy as today, when GitHub didn't exist and most of the people have very slow internet connection compared to today.
Its not about FAANG, big tech or even VCs for that matter. Its about resources, incentives and vested interests..
Building anything interesting at scale requires a group of very talented people collaborating over a period of time. This is not easy and its definitely not free or cheap.
While hobbyists and tinkerers might invent groundbreaking tech, it takes resources to propel such projects to their full potential. Resources require vested interests (skin in the game).
If it wasn't for Googles and other early adopters strong financial motive (vested interest) to avoid paying Microsoft/IBM licensing fees, linux would likely still be a niche operating system for hobbyists.
Every major OSS tech you can think is supported by either a consortium of commercial interests, a single direct commercial interest or public grants. Public grants are extremely unreliable because of reasons I will refrain from explaining to avoid the wrath of señor dang.
P.S. Git was invented by Linus out of necessity because linux crossed a threshold of complexity and scale.
Linux was popular on servers even before Google was a thing!
I'm not saying FAANGs/VCs didn't give a huge boost to the OSS tech in the last 15 years but saying that without them OSS won't be possible it's simply not true.
My lesson is - use and contribute to Open Source software as long as it's not controlled by a single company, but donated to a OSS foundation like Apache or CNCF that has a vested interest in keeping things open.
The way to kill open source is by first killing faith in it.
MS: we like "open standards", here is our implementation specific stuff.
Amazon: we don't care what would be with a project. If it is open source - we host it and get money. If it dies - people will use our closed source solutions.
Google: XMPP is soo open, we like XMPP. Oh, now Web is soo open, we like Web (we even have a browser, wondering what would happen once everyone is using one browser).
And now everyone loves open source to train AI. We would see less and less open source projects.
In the last 4 years I've spent probably 60-80% of my time writing terraform for various companies and maybe 5% of that involved a hashicorp product, and arguably, it would have been easier deploying it without terraform.
Its main use case is to build cloud infrastructure, not interact with hashicorp products.
Hashicorp isn't Oracle. It's still always useful to think about license questions in terms of whether it'd be OK if it were Oracle instead. For example, consider:
"I don't really care what license Oracle uses. It gets the job done."
If you wouldn't say that, and oh how I hope you'd never say that!, then why say it about Hashicorp? So far they've been reasonably decent, license shenanigans aside. However, remember that they're just one acquisition away from that being untrue.
I work at a place that will pay for those types of licenses. That’s my point (but we don’t need to because their license doesn’t require anyone to pay for Enterprise or Cloud)
It does the job until you have to get legal onboard, and then they will raise issues with the possibility of your startup becoming a competitor to Hashicorp
(Disclosure: I'm from Digger and OpenTF so am biased)
Hashi's biggest miscalculation is that they put Terraform (an open language / ecosystem) into the same bucket as Vault and Consul, which are hostable backend applications.
BSL makes sense for Vault, just like it does for MongoDB. It is reasonable to prevent others from charging for hosting your code.
But with Terraform, the backend part (TF Cloud) was never even open source. And it's not required for Terraform to work.
Hashi shot themselves in the foot. Unlike with Vault or Consul, there is enormous vested interest in the community to keep Terraform truly open. Hashi trying to enforce everyone to use their non-oss backend with it will only result in Hashi losing the privileged (and well deserved) position among providers of commercial products in the Terraform ecosystem.