HN Reader

From my experience, most businesses (or at least the developers working for them) actually would like to donate or pay for support on the OSS projects they rely on. The problem, at least from my experience, is that it is hard to do so due to legislation, compliance, etc.

Example: I once convinced my employer to donate to some open source projects we relied on. They did, then few months later they got slapped on the wrist by the authorities for not being able to prove where these overseas payments were going to, and that these payments weren't used for funding terrorist activities.

Similarly, I used to contribute to an OSS project, we did get asked by some corps to do paid work like bug fixes or features. The problem was that they required invoices in order for them to be allowed to pay us, so we needed to register as a company, get a tax number, etc. I was a freelancer at the time, so I offered to use my business registration to be able to invoice, then split the profit amongst the contributors. Then the very first paying 'customer' immediately hit us with a 20-page vendor assessment form asking about my SOC2 or ISO27001 certifications, data security policies, background checks of my 'employees' etc. Then I got confronted by my accountant that distributing the payment amongst other people would be seen as disguised wages and could get me into serious legal problems.

Granted, this was some years ago, things have gotten better now with initiatives as Github Sponsors, KoFi and Patreon. But at the same time legislation has gotten more restrictive, doing business with large corps is difficult, expensive and very time consuming. It's not worth it for most OSS maintainers, and similarly it isn't worth the legal headache for the large corps to make these kind of donations.

The talk that was referred to in the the article can be found here, just 13 minutes:

Keynote: Giants, Standing on the Shoulders Of - Daniel Stenberg, Founder of the Curl Project

https://www.youtube.com/watch?v=YEBBPj7pIKo

While the article does a great job, the video's graphs and photos really bring a lot more depth.

> There is an increasing crowd of people who ask a large language model to "find a problem in curl, make it sound terrible", then send the result, which is never correct, to the project, thinking that they are somehow helping.

Our worst nightmares are becoming true indeed..

>>Companies tend to assume that somebody else is paying for the development of open-source software, so they do not have to contribute.

I think if you are a billion dollar company using these tools, sponsoring maintenance isn't a lot to ask.

Curiously enough this came up even during the days of Perl.

I don't think Perl got its due, especially given the fact that even until most recently almost everything of importance was done with Perl. Heck internet was made possible because of Perl.

Step 1: Set up a GoFundMe

Step 2: Announce that, until the aforementioned GoFundMe reaches $10 million, all new commits to curl will be licensed under the AGPL.

Step 3: Profit

The Sovereign Tech Agency (German federal government) donated about 200k€ to the project. Not a brand though. https://en.m.wikipedia.org/wiki/Sovereign_Tech_Agency

If he's unhappy, why doesn't he step down? That's what I did as libxslt maintainer and what I'm about to do as maintainer of libxml2.

It would be cool to build a "library clout" measure for all open source software. First collect for all deployed software systems measures of usage per platform and along other interesting dimensions like how that system relates to others (is it a common dependency or platform for other deployed software). Use this to generate "clout" at a deployed software unit level. Then detect all open source libraries compiled in it by binary signature matching or through the software's own build system if it is open. Then a library's "clout" is built from the clout of the projects that use it.

This clout score might be used to guide investments in a non-profit for funding critical OSS. Data collection would be challenging though, as would callibrating need.

Basically make a rigorous score to track some of the intuition from https://xkcd.com/2347/

You can use LLMs as part of the process of identifying bugs, developing features, etc. but you must verify the results. Accepting what the LLM says without testing, checking, and verifying the output is lazy and likely to produce errors, or make the code harder to maintain, e.g. if what the LLM produces isn't in line with the project's development/formatting standards or changes other parts of the code.

Just have a policy of firing these "security researchers" whenever they submit AI generated BS to curl.

Every day, if I read HN, I find reasons to just go back to working on PrizeForge