The platform yes, but the runtime and the APIs are apache 2.0 licensed and uses web standards wherever possible. Thats way more open than most alternatives i am aware of.

Their fetch handler [1] is not a web standard.

[1] https://developers.cloudflare.com/workers/runtime-apis/handl...

but not to lock people in but to avoid the context overhead of service worker api, which they tried first and which still works btw.

Sorry, what? I never mentioned lock-in.

I assume by Service Worker API, you mean FetchEvent? [1] As in:

self.addEventListener("fetch", (event) => {});

That is a web standard indeed, but not one that was designed for use as a general-purpose HTTP handler, but rather for use in a Service Worker proxy.

[1] https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent

Maybe i misunderstood what you were going for. Just saying: Yes, their web fetch handler is not a web standard but the only standard there is to accomplish something like that had a few issues and they picked something that looks as generic as possible. vs import {pretendToStartServer} from ('our:global-injected-pseudo-sdk')

I really loved the idea of using service worker sdk and having something that works in browsers too so the conceptual model of edge functions are spanning backends, edge POPs and browser runtimes.

Unless the project is controlled by democratic committee where cloudflare doesn't have a majority of seats it's not open source in any meaningful sense of the word, maybe we should stop acting like corporate sourced software is anything but an attempt to get free labor from the commons.

I can assure you that nobody at Cloudflare ever thought that open sourcing workerd would be a way to get "free labor from the commons". On the contrary, we are wary of external contributions. The Workers Runtime is a complicated codebase, and we invest a lot of time into getting new team members up to speed on how to write code correctly. We cannot make such an investment in external contributors who are only there to land one PR. Usually, a one-time contributor trying to do something complicated will waste more of the team's time than they save.

But in practice, we almost never receive major contributions from outside the team. Which is fine. We're happy just to have our team working in the open.

The reasons we open sourced it are:

1. Support a realistic local dev environment (without binary blobs).

2. Provide an off-ramp for customers concerned about lock-in. Yes, really. We have big customers that demand this, and we have had big customers that actually did move off Cloudflare by switching to workerd on their own servers. It makes business sense for us to support this because otherwise we couldn't win those big customers in the first place.

Have you seen the codebase? Please don’t blanket reply like that just because it is a corp. Workerd is one of my favorite piece of engineering and its not comparable at all to openwashing projects that have extreme internal garbage not possible to free from the companies infrastructure. Kenton and others fought hard to make the abstractions among the cleanest and well designed in the industry and while it is not a multi contributor apache foundation style project it is a codebase that you could hard fork if cf decided to close it or go a direction you cannot accept.

> maybe we should stop acting like corporate sourced software is anything but an attempt to get free labor from the commons

The point of this discussion is that you can self-host, and you have a good chance of migrating the code away entirely. That's a big benefit that isn't "an attempt to get free labor". For that use, not only does it not matter if it's meaningfully open source, it doesn't matter if it's open source at all.