Partially. Yes. Look at the budgets of these orgs and you'll see what I mean.
I use the term similar to who it's used for non-profit. The orgs I'm involved with are almost exclusively not involved in the actual standards creation.
If the secretariats were to shut down tomorrow I'd say the actual work on the standards could continue without anyone noticing.
As someone working in standardization: I don't know any standardization organization where the people doing the actual work of writing standards are paid for their work. I certainly am not.
In the organizations I know - including ISO - the money is basically exclusively spent on "overhead".
Because of bureacratic overhead. We did employee people from other EU countries in the past because I personally honestly don't care where someone is from or where someone lives. But you need to learn the rules of every country. And they are often subtly different. We even struggle with UK & Germany already. It's annoying. And we have like 0,1 FTE to take care of HR stuff and anything "out of the ordinary" eats into that time and money budget.
The rules need to change. The rules will not change. So we're stuck.
It's not us. It's the customers that struggle with the pace already. In the enterprise world we operate in having more than one release a year is already considered breakneck speed.
Stackable | Product Engineer - Web & UI | Remote (Germany/UK) | ~20 people | Full or part-time
IMPORTANT: ONLY APPLY IF YOU ARE PHYSICALLY BASED IN GERMANY OR UK!
(I received almost 100 applications, about 85 of them did not read the details)
We build an open source data platform on Kubernetes.
The product (Stackable Data Platform - SDP) bundles 12+ open source data tools (Trino, Apache Kafka, Apache Airflow, Apache Superset, etc.) and makes them work together.
Right now everything is Infrastructure-as-Code only. We need someone to build a UI layer on top.
No mockups, no Figma, no product roadmap waiting for you I'm afraid, just a bunch of ideas :)
We're all backend people and need someone to own this end to end. Play around with our product stack, figure out what customers actually need, build it.
Stack (because we got started without you...): Svelte/SvelteKit, TypeScript, TailwindCSS. SDP itself is Rust, Java, Python on K8s.
Three releases a year. Not SaaS. Quality matters.
100% remote, Germany (UK possible) only, no other countries, sorry. No Scrum, minimal meetings. Interview process is usually just two conversations.
The position isn't on our homepage yet as I'm on vacation.
Send a mail to [email protected] and I'll get back to you next week. Please mention HN in your mail. My personal mail is also in my HN profile. I'm the Co-founder and CTO.
This is a terrible idea in my opinion and it's been tried/is being tried by services like thanks.dev. Yes, we need something here but this is not it. The reality is more complex.
It doesn't work well in practice. Because then people like https://github.com/sindresorhus?tab=repositories&type=source would get a shit ton of money because of the pure number of dependencies. And yes our stack also contains his code somewhere in a debug UI but our main product is entirely written in a different programming language with way fewer dependencies but if one of them goes away we'd be in trouble. In other words: Dependency count is not a good metric for this.
My "idea":
Lots of companies will have to create SBOMs anyway. Take all of those but also scan your machines and take all the open source software running on there (your package.lock does not contain VLC etc.) and throw it in a big company wide BOM, then somehow prioritise those using algorithms, data and just manual voting and then upload that to some distributor who then distributes this to all the relevant organisations and people and then (crucially) sends me (as a company) an invoice.
We've tried doing the right thing but sponsoring is hard - it works differently for every project/foundation and the administrative overhead is huge.
The reality is that "we" as an open-source community suck at taking money and I believe this is partially on us.
I'm no expert but a far stretch but if this most basic fact is already wrong then my trust in the remaining stuff diminishes. On top of that they is only relevant if all truck loads were limited by weight.
So, I believe that argument to be wrong in its entirety. And if we then factor in the CO2 costs, hydrogen is the clear loser in all regards.
In case it makes you feel better: I wondered the same thing. It's not explained anywhere on the blog post. In that poste they assume everyone knows how pricing works already I guess.
Basically it's a k3s configured to use a local mirror and that local mirror is running the Zot registry (https://zotregistry.dev/v2.1.8/). It is configured to automatically expired old images so my local hard drive isn't filled up).
There is a process, it's usually tedious but it exists.
I did it for Singapore, the US and Israel. They mostly took multiple months but I never wanted to take any chances. For the US it was a "B-1 in lieu of H-1B" visa for example.
Attending a conference is something different than what these workers did.
There are rules around what a "business trip" is and what is not and what "work" is.
Not commenting on the substance but on the https://opensourcemaintenancefee.org/ homepage itself. It only works in dark mode and is unreadable in light mode.
The repo doesn't allow opening issues. Maybe the author reads here... (long shot)
I agree with your examples but I think a piece of software is different because users expect it to change over time.
New Mac OS version? Users want <software> to support it.
Found a bug in a library <software> uses? Users expect to get a fixed version
etc.
And while as a software user/buyer myself I like the idea of paying once and be done with it I kinda understand why people need recurring income if they keep on working on a piece of software even if it's just "minor" things.
I use the term similar to who it's used for non-profit. The orgs I'm involved with are almost exclusively not involved in the actual standards creation.
If the secretariats were to shut down tomorrow I'd say the actual work on the standards could continue without anyone noticing.
There is a reason that at least the EU is considering modernizing the system. https://single-market-economy.ec.europa.eu/consultations/pub...
ISO, CEN, CENELEC, ETSI are stuck very much in the past.
So yes. Overhead.