Clojurians Log v2

Behind VB, Raku, ADa, Fortran... Jeez Never even heard of LabView. I think the original link was to https://spectrum.ieee.org/top-programming-languages-2025

depends a lot on what is measured.

making average choices is a good way to get average outcomes 🤷‍♂️

Damn, last one in trending. We need to get it back in the hype cycle

I personally think a guild model could be more suitable, it presents less perverse incentives. A reified effort in form of tokenization is another solution. eg make bigcorp mine mavencoin to download from maven

Unions might have been suitable when labor was dirt cheap. We're craftsmen, there's a working model

Good to see the "elephant in the room" (OSS sustenance: creation, maintenance and delivery) discussion happening. @sludwig.dev’s observation about union logistics across countries is pertinent. It's quite clear that OSS does not have any inherent economic model - it needs to be associated "out of band" with an incentive model.

I see a distinction between what we saw with ruby gems and general overworked oss maintainer like libxml2 or libcurl. The latter is a clear tragedy of the commons scenario and it can be solved by not working for free. Be advised that signing a support contract will buy you liability and other unpleasantness. With a case like the former, I tried to analyze it adversarially and came away with a conclusion that in Shopify's position I would have done the same. There are solutions but non of them are fun or make anyone feel good or happy.

Can anyone report on real-world experience with the approach of providing software free for non-commercial use, but requiring a paid license for commercial use (at least above a certain revenue threshold)? Can this work without closing the source and implementing DRM? Would (enough) large companies abide by the terms to avoid license violation? (I can see this being historically hampered by payment logistics, but it's pretty easy to securely accept payment these days.)

It'll probably be hard to get users to disclose their revenue if they're private. Could be Metabase has a right model.

If it is the usage that is the problem + expensive, and not something else that is bothering you, it seems like you could solve this pretty easily by forcing them to create a mirror/cache that they point their tools at instead the central repos.

@selahb There are few possibilities (YMMV in the field) - AGPL/proprietary, FairSource/BusinessSourceLicense (allows non-commercial, restricts commercial), Server-side Public License (SSPL).

I want to highlight that if there was a "if everyone just..." solution that worked we wouldn't be having this conversation. Though it is a good exercise to talk through why all these different things have not worked

Sure—the idea wouldn't be to apply any sort of enforcement (which would be impossible and probably counterproductive), but rather to rely on enough orgs above a given size to either "do the right thing" or short of that "do the thing that doesn't put them in legal violation of the software license". For a large org, paying a (for them) nominal fee just to avoid even the remote possibility of litigation is a no brainer. (Plus this sort of thing gets reviewed during acquisition due diligence.)

Maven, except it is more like bittorrent that tracks seeding ratios, change my mind

Dead torrents are common and you don't actually want that for infrastructure

Its just distributing the cost to more volunteers, not solving the "volunteers are paying the cost" problem

Fair

I also think it makes all the trust/supply chain attacks we have now even more pronounced

To be clear, I'm talking about OSS in general vs. specific code distribution hubs like npm and maven. It seems like many devs may be reaching for very permissive licenses (like MIT) by default, when more restrictive licenses (per @kumarshantanu) would benefit both their own work, OSS at large, and ultimately commercial enterprises that rely on it.

Yea torrents are out, you're probably right. Maybe blockchain + proof of storage credit type system could work.

blockchain solves no issues ever, rule of thumb

Well everything proposed here is hard and impossible

torrents + blockchain = IPFS

The anarcho-primativist-computer in me says maybe the infrastructure itself shouldn't be around in the first place, ultimately. Return to the primordial soup of torrents and mailing lists.

so its not like that needs to be invented. Its just crypto-ing up a funding mechanism

but those aren't immune to abuses - rather those seem way more prone to them. I don't think there is going to be a "pure tech" solution here

I'm trying to think if there is a solution that doesn't require convincing people to do the right thing, since that is pretty hard too

I think the issue with what you are talking about @selahb - even presuming you could convince people to use more restrictive licenses - is that running a business has significant overheads. In time if nothing else. In practice people will still be unpaid volunteers + we still haven't touched the infra problem

now if everyone runs that business together maybe, but just like how every time people talk about a hyperloop or whatever solving the problems with it just leads to making trains again, i feel like all roads lead to a union of some sort

I have some doubts regarding using a sort of reified work solution, even though I think it's good and generally like crypto. Any large corp will mirror repositories anyway, their volume will be significantly filtered through that

small project, even commercial? Sure use my library! large company? Sure, use my library! - but you need to contribute to the open source infrastructure fund or we as a profession withhold labor.

that doesn't need to be in the license for the library, just a condition in reality

> large company? Sure, use my library! - but you need to contribute to the open source infrastructure fund or we as a profession withhold labor. One aspect of this reduces down to a resource allocation problem - time isn't free. Want support? Have an urgent issue - make it worth my time or I'll get to it whenever. Infrastructure is different, need to think of a solution here. Ideally one which alleviates supply chain concerns

but options for that level of support exist; they are not paid for. It needs to be taxes, not opt-in

I've often wondered why have mirrors not caught on in the Maven world as opposed to the Linux/OSS world. (Independent of supply-chain attacks concern.) Potentially, a slow master/fast mirror could encourage big players to have their own corporate mirrors?

What would be the downside of maven et al offering an "enterprise" tier with paid support and SLAs, and first class passengers can subsidize the rest of us?

What would the upside be? Why should anyone care about that level?

@selahb they already do that

the perverse incentive of the current system is to design things that are easy to implement and ship, and become so hard to maintain that you need a consultant (available at market rates from the developer of the framework)

this can easily happen accidentally without malice, but there's no need to add incentive to it

Who needs Maven? Sure, if Maven Central imploded it would be a momentary inconvenience for many - to finally switch to deps.edn and draw libraries direct-from-git. Only closed-source relies on Maven for ubiquity, and they do it to make money, so let the closed-sourcers pay for it. No?

Compiled .class files.

That doesn't change the nature of anything. You are just swapping Sonatype for Microsoft

Git is distributed

So, technically, can a maven repo be

Which would solve the .class file problem

That is, I foresee that NPM and such will all be overtaken by direct-to-git, any git server

Cut out the middleman & they won't need to be paid

Now you not only rely on an overworked libfoo maintainer to provide the patches, but also to run a gitlab on his homelab so that all the deps.edn-powered folks can pull from it during CI runs:).

I don't understand why you would think that. People put their repos on github. They don't often self host things, and if they do ^

Thats a "metal gear solid villain" answer to the problem. We'll get rid of common infrastructure to force people to be self reliant! Solid snake I have you now!

Money does not seem to be a problem for github and gitlab... they offer paid services and could expand those

I am sort of skeptical of the altruism of Maven Central. I have no doubt it's a money-loser. But it is central social media.

They may not be effectively monetizing, but surely there's a market for "who-all uses what-all"

Why are we shutting down Maven, again?

theres not a market for fire departments - infrastructure for the public good doesn't work on those terms. Its why the post office being forced to run as a for-profit is silly

Not to detract from your point, but it is possible to run a for-profit "post office" (DHL, FedEx, many other private intra-country shipping companies).

they just become private companies, no longer services for the public good. Things get worse

Imagine a privatized for-profit sewage system though. Damn... I can almost see it already, the future is so bright. Toilet subscriptions here they come.

On the low-flush "plan"

I like Leiningen. Maven is comfortable once you reach an accommodation. But it just seemed to me that the conversation about a worldwide software union to support such things (if their current donor stepped away) was premature, because if push came to shove, the world knows how to do without the likes of Maven Central.

well points to highlight: 1. They are claiming that all package repositories face similar issues of abuse 2. This isn't the only kind of public software development infrastructure effectively kept afloat by altruism 3. The actual development of the software that runs the world has this problem as well. If I did research and mauled 10 people in utah while dressed in a bear costume, not only would I not get caught I could probably grind the software industry to a halt

this isn't a "everything's fine, folks would adapt" thing. Its a "we're kinda transparently teetering on the edge" thing. That's what "unsustainable" means - the status quo will eventually fall apart in some way.

1. But R. Hickey demonstrated empirically that nobody needs them. So of course they're facing issues. They were sitting on a gold mine that turned to sand. 2. There was probably another example somewhere, but I missed it 3. See Clojurists Together

> But R. Hickey demonstrated empirically that nobody needs them In what manner was this demonstrated

deps.edn goes straight-to-git

that just makes the server hosting the git repo the package repository

And Github &c seem to be doing just fine. And charge for repos. So, someone will have to pay -- wasn't that Sonatype's hope? -- and it might be the artists. We'll see.

git is no more fundamentally distributed than a maven repository

at least in terms of the actual hosting of artifacts

> And Github &c seem to be doing just fine. Github sold to microsoft

There are multiple realistic git providers and there could easily be more. Thing about git is, you need it anyway and the business model is better proved.

Maven is strongly geared toward one central thing. deps.edn might be - I don't know - but need not be.

I choose to believe you'll take a nap and wake up going "ooooooh"

Interestingly, Github package registry supports Maven packages: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-apache-maven-registry - it requires authenticating to Github, so the consumer is tracked. Probably easy to identify/bill the whales this way.

I'm all for switching everything to git deps over radicle, but what do we do about those pesky java deps?

I seem to recall that Docker Hub had a similar issue, and seems to have solved it with rate limits for users that aren't paying.

The issue that we discuss seems a bit strange to me because big companies I worked for had a caching Artifactory layer, primarily for security/build reliability reasons (and it reduced the pressure on the Maven proper as a side effect). I agree that public infrastructure services are free to rate-limit such abuse (I'd call the lack of caching an abuse).

Who pays for it now ? And also who pays for Clojars ?

This does look like a zero trust problem that blockchain or ipfs would presumably solve but the monetisation incentives of these solutions are not aligned with the objectives of the solutions at all. Larger companies usually have their own proxies to cache a stable working version of these libraries, the costs imo are primarily from individuals and small-mid size companies that dont do strict quality control over their dependencies.

Caching proxies still account for not insignificant volume, but we'll have to see statistics. Besides, this only reifies the work associated with infrastructure, not with maintenance or development