Re: [community-group] How library and tooling authors do keep track of conformance and changes? (#247)

> What struck me was the level of repetition we all suffer from.

I’m just asserting my opinion here, but I think ideally this is how Open Source works? Having more implementations, and more options, only benefit users.

Take YAML, for instance. It has a central specification defined of how it _should_ work. But the group that wrote that specification aren’t responsible for porting it into every programming language; that’s done by hundreds (if not thousands) of individual developers. The end result is, yes, there’s a lot of “repetition.” But each individual implementation works extremely well for the users it’s serving.

I always view this as a feature, not a bug. Anyone being able to create their own library and open source it is always a great thing. And the community is always benefitted by _more_ open source projects, not fewer. OSS is a lot of work! And there’s a real resource cost to trying to centralize implementation and put the burden on the standards committee, rather than distributing the load across developers, with many people being able to do part of the lifting.

But that may just be my viewpoint—I just don’t see GitHub projects “competing” with one another. I all view it under the same umbrella of collaboration and mutual sharing. That is, as long as it’s open-licensed and there’s not money/profit involved 😉 

> Taking this step back, I feel like we would all benefit from a npm package that would host the types and the most implementation-agnostic definitions.

I do agree with this though! Though maybe not an npm package, since that only benefits JS/TS tooling (and I’ve seen Rust, Go, and Python DTCG tools, to name a few). 

I’d love to personally see an official [JSONSchema implementation](https://github.com/design-tokens/community-group/issues/107), hosted by the committee. I think that’s a good balance of:

1. Low-effort (relatively-speaking)
2. Beneficial to users and tooling maintainers (TS types could be generated from that, theoretically)
3. Universal to all programming languages (fits in with the design goal of DTCG being JSON to begin with)

IIRC there are some current barriers to this working fully with the current design, but this may be achievable in the near future? But I haven’t looked into it in a while, admittedly.

-- 
GitHub Notification of comment by drwpow
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/247#issuecomment-2299200496 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 20 August 2024 15:58:05 UTC