Ask HN: How to get compeitors to use our open source interop-prototcol?

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • OpenCannabis

    Discontinued Central monorepo for the OCS specification.

  • api

    Proposal for Common Data Models and APIs for Cannabis Software (by openthc)

    We make open-source software for the cannabis industry, there are roughly 150 other software providers in this space, and we all need to share data (Lot details, Crop details, Product details, Lab Results, etc). Around 2018 or so we published a OpenAPI specification for data models ( https://github.com/openthc/api ) that we were hoping to get others to participate in. It's been rather difficult.

    The previous blocker was that in much of the USA, this data flows through a central system operated by the Government (as a contract to BioTrackTHC, Metrc or Akerna/MJ Freeway/LeafData). So, there hasn't been a critical need for interop. However, recent states to legislate cannabis (Oklahoma, Maine) don't fully have that and one (Washington) is moving away from theirs at the end of the year.

    The Washington state one is now, finally, getting some eyeballs to our API model. We'd been inviting these compititors for years to participate but it was crickets. Just recently a trade association stepped up efforts to get some parties to the table. After a few meetings we still haven't been able to even agree to agree. It's frustrating to be asked over and over if we're OK to have others contribute (TF!? we've been asking them for years). And the conversations go in circles:

    a) what if we don't get everybody to participate? (we won't)

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • sgr

    sgr (command line client for Splitgraph) and the splitgraph Python library

    Federated data sharing is the core use case of the magic Postgres database we’re building at Splitgraph [0]. We’d love to help you solve these problems! The ideas you’re describing are exactly what we want to achieve – data sharing should be as easy as changing a connection string in a SQL client. It sounds like your use case would be a good fit for what we’re building. If you’d like to learn more, please send me a note – email in profile.

    [0] https://www.splitgraph.com

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts