Projections are useless. The past does not predict the future.

BLS is useless for the same reason, amplified.

There is data on average software salaries and job counts.

Salaries have not grown since 2021. Inflation is high in the same time period, meaning pay is substantially down over the last five years.

Actual jobs are harder to measure but various sources all show swings of +\-5% each year.

Salaries are down 10%, and best case scenario jobs are up 5% in that same time frame.

And I’ve experienced 500 error codes in Claude code that lasted more than thirty minutes but less than an hour that never showed up on the status page as an outage

Now a single question consistently uses around 15% of my quota

Once people won't be able to think anymore and business expect the level of productivity witnessed before, will have no choice but cough up whatever providers bill us.

Is that bad? After all, even if they hiked to price infinity, you wouldn't worse off than if AI didn't exist because you could still code by hand. Moreover if it's really in a "business" (employment?) context, the tools should be provided by your employer, not least for compliance/security reasons. The "expectation" angle doesn't make sense either. If it's actually more efficient than coding by hand, people will eventually adopt it, word will get around and expectations will rise irrespective of whether you used it or not.

This was addressed by the words that you perhaps mistakenly omitted from your quote:

> Once people won't be able to think anymore...

People who aren't able to think anymore, can't still code by hand. Think "Idiocracy".

OpenAI and Anthropic have been getting stingy with their plans and it's only it's been what, 1 year, maybe 2 since vibecoding was widely used in a professional context (ie. not just hacking together a MVP for a SaaS side hustle in a weekend)? I doubt people are going to lose their ability to think in that timespan.

My argument was not about AI. Rather about the practice of Anthropic and the likes.

If the AI companies made their pricing "pay as you go" without quotas, a few insane zealots (power users) would occupy all the capacity and choke everyone else out. Regardless of the cost, the AI providers would lose the ubiquity they currently enjoy, and become a niche tool for rich tech people. They would rather be a mile wide and an inch deep, doing a worse job serving millions of users, because there's a better scaling narrative for legislating and fundraising that way. Like the advertisers there are intolerable indirect effects of letting valuable "power users" spend more money to get a better experience.

I suspect more customers are lost a lot faster when you increase prices, compared to enshittifying the product. It's also a lot more directly attributable to an action, and thus easier for an executive to be blamed if they choose the former over the latter.

It occurred to me an outright rejections of these tools is brewing but can't quite materialise yet.

OP wrote "I pay for the lowest plan", so that’s the $20/mo one.

I also strongly disagree with most of the criticisms of crates.io, but…

We are owed supply chain security. The moment a group says “use our stuff for critical projects” they take on some baseline level of responsibility for making things secure.

You cannot offer a taxi service in a car that is not fit for the road, and then just shrug when it crashes a people get hurt.

The good news is the people behind crates.io and the Rust ecosystem care about security. They have given conference talks about what they are doing behind the scenes. Features like Trusted Publishing are a huge step in the right direction.

As far as I can tell, the issue is not with the crates.io team, but funding and incentives as a whole. We all rely on critical infrastructure like package managers, but not many are willing to fund big security improving features.

Every popular open-source license explicitly states that exactly the opposite is true:

Apache license: "Licensor provides the Work (and each Contributor provides its Contributions) on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND"

GPL v2: "THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND"

Mozilla license: "Under no circumstances and under no legal theory, whether tort (including negligence), contract, or otherwise, shall any Contributor, or anyone who distributes Covered Software as permitted above, be liable to You for any direct, indirect, special, incidental, or consequential damages of any character"

BSD license (both 2 and 3 clause versions): "THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES"

MIT license: "THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND"

You are and have always been on your own when using open-source software. Nobody owes you anything.

I know that doesn’t apply 1:1 to software, but the point is less about individual OSS projects and more about the hosted service of package registries, which do have people & money behind them.

Npm, for example, is owned by Microsoft (through GitHub). MS has huge amounts of money. They could be scanning for malware on upload and adding so many more security mechanisms. But they don’t.

Developers have an ethical responsibility but that doesn’t mean they should be legally accountable for genuine mistakes.

If I open source something, I am not your parent, if you decide to wing it just because it is open source that is your problem not mine.

You are not obligated to use anything anyone open sources. If you can't take responsibility for your own actions that's on you, not the person who open sourced it - that is what generally all the licenses state to begin with.

I think you’re being overly simplistic with your position because there is a sane middle ground where maintainers are honest about their projects (eg so often pet projects have readme’s that describe POC code as if it’s production ready, and that’s not ok)

I’m not suggesting that users of open source packages don’t also have responsibility to vet the packages they import. But so often I’ve wasted time vetting a package that has made bold claims in the README only to discover it’s basically beta software. And that can be hours of my free time wasted just because the author wanted their CV to sound more impressive.

On my open source projects, I very clearly list when things are going to be beta quality, where experimental code lives, and where stuff is tested and considered safe for production use. I do that because I value people’s time. Just like I value my own time. And it only takes me 2 minutes to add that detail to the readme.

We are talking about developers having ethical ownership for communicating their project responsibly.

That means being honest about when a pet project is just a pet project rather than talking about every POC as if it’s production ready.

And it’s disingenuous to spin this as “only trillion dollar companies use open source” because we all know that isn’t even remotely true.

And who isn't honest about it? Read the contract you have with the provider.

There is a way to legitimately expect production-ready libraries: You sign a purchase order for the right to use that code for a year (typically, or multi-year) and pay a quite substantial amount of money for that. Then you have purchased the right to expect a certain level of quality (details can be in the contract and reflected in the price).

If you're using something for free without having agreed to such a contract and paid the vendor accordingly, then you can expect exactly as much as you paid for it.

If you, or anyone else, thinks that is an unfair assessment or that I should have to pay for a README not to claim to be production ready when it’s a POC, then you had a very weird view on how much effort it takes to write the line “this is an untested beta”

The state of expectations is usually in the LICENSE file, not in the README. But it's there in the repository, in most cases.

I do agree that some maintainers forget to include the LICENSE file (or equivalent), which is a mistake. The terms of use are quite important.

No it’s not. LICENSE tells you what you can do with the code. It doesn’t tell you the state of code.

Again, I need to reiterate my point that I’m talking about whether the code is beta, tested, etc. It costs nothing for a maintainer to specify how complete a code base is.

It’s then up to the consumers of that package to decide if they want to use it, contribute back or just fork it.

All I’m saying is too many GitHub repos are written for CVs; as if they’re meant to be consumed by Google. If something is a weekend project then just be honest and say “this is a weekend project written to solve my specific use case but PRs are welcome”. Thats better than having long blurbs that refer to the solo developer as “we” and all the other BS people stick into their READMEs to try and make their project sound better than it actually is.

All I’m asking for is a little more pragmatism and honesty in READMEs. It’s no extra effort. It’s no extra cost. And I shouldn’t have to donate to projects just to ensure they don’t lie to me.

Of all the files in a repo, the LICENSE file is the one most important to take literally since it is a legal document.

So when it says something like (this from MIT license):

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

That is actually exactly what it means. There is specifically not even an implied suggestion that the software is suitable for your use.

If you want any kind of guarantee of the code being of any use to you, sign a contract and pay for it.

Unless you pay for that contract, nobody owes you any kind of hint as to whether the code is useful for anything. It very clearly says so in the LICENSE file.

And your comment that I should pay every…single…maintainer of every…single…project on GitHub, just for them to disclose whether or not their project is experimental… well that’s just insane and completely misses the point of open source.

If we are talking about businesses relying on open source libraries then that would be a different matter. But not ever fscking thing being built is a VC-backed startup.

I say all of this as an open source maintainer. Just be honest in your READMEs.

A little honesty in the README costs nothing and we should be expecting more of it. And suggesting we lock that honesty behind a paywall is possibly the worst idea for open source imaginable. That simply isn’t the right way to monetise open source.

Edit: just to add, even if we were talking about software quality (which we wasn’t) paying for software doesn’t guarantee to you a better product. I could name a multitude of commercial solutions that I gave up on because the open source alternative was at least equivalent. But often even superior. And that’s before we talk about then enshitification phenomena.

Edit 2: sorry for all the edits. I should have just waited until I had proper time to reply calmly rather than commenting while doing chores and stuff around the house. My bad.

The license (most, anyway) clearly state the software is not necessarily suitable for any purpose and that's all you get.

If you require a higher level of confidence than none, then you should be paying for a support contract.

All I can say without being repetitive is that if you expect more than nothing when the license specifically says all you can expect is nothing, you might be disappointed more often than not.

And why you describe absolutely is not how any of more reputable libraries nor maintainers approach open source software.

So you might feel like you are legally correct. But you’re still completely missing the point.

Anyone who is not paying me can use what I generously give away for free without THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Concerned about security? Good for you, build it yourself.

The problem is that there's no overt way to tell whether the "car" (code) you're looking at is someone's experimental go-kart made by lashing a motor to a few boards, or a well tested and security analyzed commercial product, without explicitly doing those processes on your own.

The problem is all the go-kart hobbyists who make moderately popular go-kart designs end up being asked for all sorts of commercial territory requirements.

The people on the consuming end think "reliability is their job!" and try to force all their requirements and obligations onto the go-kart makers, which usually doesn't end well.

Yes you can, companies just don't like the answer.

To run with that analogy, if you are setting up that taxi company, will you build your fleet by picking up free gokarts around the neighborhood, or by purchasing cars from a known manufacturer who has gone through crash testing etc?

Not particularly different for software. If you need certified quality, you need to pay the providers fairly substantial amounts of money for that.

If you’re using a security package and it isn’t either a shim over an existing API (eg porting a C-library to a non-C language) or it fails to provide evidence of independent audits, then steer clear or it.

Most other domains are generally much easier for the developer to audit.

However I will say in an age of AI, it will become much easier than it already is to inadvertently pull bad packages.

In arch Linux, I trust the base repositories more than AUR.

1. Consumer protection, product safety, and liability.

2. Truth in advertising, fraud prevention, etc.

3. Freedom of expression, association, publication, etc.

There is legal precedence in concepts like "attractive nuisance" to put the liability on a producer or owner not to allow the naive public to encounter their dangerous constructions. But we generally allow for media to illustrate such things, i.e. you can depict dangerously unprotected swimming pools, booby-traps, or poisoned food distribution in a book, image, or movie. You get in trouble when you put any of this in the real world though.

This is particularly confusing with software because of its duality as being something like speech or media that we can publish and also something like tools or products that can be manufactured, distributed, and consumed with observable results in the real world.

Who is liable when the unsafe software is distributed and converted from speech into machine action by naive end users?

If you actively advertise and give away free food, there is a baseline assumption that you are at least cooking the food in sanitary conditions.

If people get sick after eating the food you gave them, you can’t just shrug and say it was free.

Any software you use with this clause, "THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."

Already attests that the authors do not offer guarantees that the software will have the features you need, supply chain security or otherwise.

Blindly pulling updates from providers that offer you no contractual guarantees has to be gross negligence right?

The software is provided as is.

IANAL.

If I mix some ecoli into your drink mix, I did this on purpose. You just don’t know it until it is too late.

Are you liable for allowing this to happen?

Let's take npm. The postinstall scripts and auto fetching of dependencies have always been seen as problematic. So plenty of warnings beforehand, but people chose convenience over security.

Debian's package management has the same feature (postinstall scripts and dependencies management). But the risks are lower, mostly because your main targets would be a core group of committers, which I'd like to believe is more conscious about security risks. And there's a lot of reviews before binaries are built and made available in a stable version. And I'd also like believe popular packages like nginx, curl, coreutils, postgresql,... have a lot more eyeballs on them.

In the context of commercial food safety, we can have your discussion. Outside of commercial activity, you are accepting all risk with consumption of home baked goods. There are no guarantees around cooking area cleanliness, hygiene, status of ingredients, cooking methods, or any of those guarantees. No legal system with give you a standing to levy an action against someone in that case. Especially if ultimately, you elected to use that code/eat the treat. Now, if you can prove, mal-intent; they made a batch of brownies, other people ate brownies, but you specifically got sick after being served a sample by the individual; then you might get some extra attention, but that has a much higher bar of proof.

So yes. If you get the one bad brownie out of a batch I cook in my kitchen for the potluck you ate at knowing the risks, that's on you. I'd be mortified personally if it happened, but in all likelihood it was accidental. You aren't paying me, and I'm doing it because I want to, but everyone does ultimately accept some risk.

Same goes for physical manufacturing supply chains too! QA is WAY more strictly enforced through contracts and vendor agreements with pre-defined, agreed upon, and often voluntarily entered into audit processes defined in mutually entered into contracts. It's the QA groups task at a step of the process to audit inputs for conformity to agreed upon Quality Standards, and to assure, and guarantee through Quality Control the specs are met for the next link in the chain, and to be audited for such compliance by the QA group at the next link in the supply chain. The key here is a shared, compelling, and formalized commercial interest, solidified through shared investment by all parties in the chain. That does not exist in FLOSS. The vast majority will never pay you, or enter into any supportive relationship with you. In fact, most code is written to the standard of "I know how I'm going to use it". If I'm not dealing with OWASP top 10 or what have you in my context, I'm not making my code handle it. Not my problem. I also don't have guilt sharing it either. You use it in a way that it's dangerous to you, that is on you.

If this angers you, fine. But while I personally understand where you are coming from, I've been around long enough to know that it is absolutely the case that if you want baseline duty of care to everyone who comes across this product regardless of my purposes I designed it for... There will be no more shared code. Nor will we share specs either.

Open source is fundamentally a gift culture from the authors: here's a thing. You can use it for free; it may or may not meet your needs; but I do not owe you anything either way.

Take it to the extreme. What if I write a library, put an OSS license on it, advertise it, and then bundle malware in the release.

Am I fault for including malicious code, or are the users who downloaded it entitled for expecting the code, that I asked them to use, will not harm them.

I would argue the burden is mostly on the user for smaller niche projects, but mostly on the developer for large, heavily advertised, critical infrastructure projects.

It is not entitlement to expect operating systems, package managers, browsers, etc to be following good practices.

It is the definition of entitlement, because what you are claiming is "good practices" is actually "ongoing labor and active management."

And, again, contravenes the license you agreed to. If you don't like that, you should execute a contract that does offer the support you want.

The last person, I think, most clearly, does "owe" you supply-chain security, in the sense that he bears moral (and ought to be made to bear professional) responsibility for any adverse consequences you may suffer from its lack, though in practice he will probably often protest that he couldn't do anything about it because it's not like he is developer. Whether the developer also owes it is a more interesting question, and I think it greatly depends on what attitude he takes towards the evangelist (does he consider him a nuisance who makes implicit promises the developer is uninterested in delivering, or an ally who raises the dev's profile?).

Long ago, I remember seeing a cartoon which involved a tag-team of two people robbing a third, with A pointing a gun at C and saying "give your money to B", while B comments "I'm really just standing here, but I figure it's best if you do as he says". I'm not sure what exact piece of day-to-day politics this was made to comment on (though it was probably some or another flavour of political violence), but it seems somewhat applicable here as well. The lines just become "accept the supply chain, or suffer my public ridicule" and "I'm just providing the software 'as-is', but you probably should do as he says".

This is doing a lot of heavy lifting, and not really valid as a categorical statement. It's important to narrow the context because "Free software developers" are ultimately still people or organizations that fall into our established systems. There is no specific purchase contract between the provider and user, so unlike commercial software that supply-side obligation is not explicit. There's typically a license that tries to legal-away any responsibility, and this is not so clear-cut. Free software is not found at the side of the road without any providence. It's usually the product of one or more legal entities, promoted, it's use encouraged and maintenance & delivery can be implied by the actions of the developers. All of these things carry varying degrees of obligation within legal, cultural and social frameworks. We try to reduce this down to "no obligations" or "expectation to support for free in perpetuity" but no binary position is accurate.

Careful, requiring that might get you completely unmaintained software instead.

I disagree. Security is always a trade-off.

Owning, auditing, and maintaining your entire supply chain stack is more secure than pinning hashes, but it is not practical for most projects.

Pinning your hashes is more secure than not pinning, and is close to free.

At the end of the day, the line of trust is drawn somewhere (do you audit the actions provided by GitHub?). It is not possible to write and release software without trusting some third party at some stage.

The important part is recognizing where your "points of trust" are, and making a conscious decision about what is worth doing yourself.

The blog is mostly focused on hardening the CI/CD pipeline.

Your sessions were probably getting auto-compacted much earlier before the context window got larger.