Post

Boris
@bmann.ca

One of the challenges here is that "developer relations" in other open source or company contexts is around a single codebase, an inside & outside. So for me, this is "ecosystem relations" & networked orgs, which are subtly different. e.g. there are no third party atproto developers.

0 reposts31 likes

Benjamin is ... making a game
@benjaminlistwon.com

"there are no third party atproto developers." This is the other big takeaway for me: Bluesky is a business, Atproto is an open-source protocol, the sooner they operate independently the better. Atproto should have its own governance (beyond IETF work), its own devs, its own funding. ...

Benjamin is ... making a game
@benjaminlistwon.com

Once Atproto is independent, Bluesky can open PRs or issues against the protocol like everyone else. Protocol maintainers are free to prioritize what the entire community benefits from accordingly, and other teams are free to innovate on top of it however they want. This is the way.

Trezy
@trezy.codes

I’m not sure I see the value of that distinction. Both are built for effectively communicating with a community, regardless of the integration points.

Boris
@bmann.ca

If you haven't been doing much ecosystem relations then it can be challenging. Probably should have been called Bluesky Report too Something like (not fully fleshed out): protocol (pre standards) -> protocol IETF -> ecosystem -> implementation codebases w/ contributors -> operators -> etc