8 ms·
Ask HN: How to get compeitors to use our open source interop-prototcol?
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)
b) what if the model is not perfect? (it's not)
c) what if you (OpenTHC) take some nefarious action? (on MIT licensed work, in a public repo? feels like a bad-faith question)
d) what do other industries do? (they have a common data-model (eg: GS1))
e) what if we don't get everybody to participate? (we won't)
f) repeat while (true);
Then after the meeting, we get stuck in one-on-one meetings with the same parties from the group sit-down; and talk the same circles; and deal with finger pointing; and re-explain how common-data-model helps us (why are we explaing this to CTOs and techinical founders?). Sometimes it's even suggested to form a NEW association/group for this. It would be disappointing in our efforts to reduce the number of interop-protocols we actually create another one! ( https://xkcd.com/927/ )
We don't think the API is too complex, the models are very simple and (we assume) that everyone knows distributed/federated systems are a good design goal. We've offered many times to help with integration, run pilot programs, or talk through models. In fact, some of these informal conversations have led directly to changes in the model -- it's just the person giving the feedback won't do it publicly, there's no Issue filed, no PR -- and we still don't actually move forward on the integration; and the project doesn't have the community feedback publicly documented -- so it looks less "strong" than it really is. Many of the vendors have APIs (unique, bespoke) but they are just slightly different (eg: Area vs Section or updated_at vs updatedAt) and none of them are posted for community use and feedback and all that FOSSy stuff; so at the moment we're like the only one out there.
a) what are we missing?
b) any tips on getting competitors to agree on interop-protocols?
c) what are we doing wrong?
d) what lesson did we miss?
The industry (cannabis farmers, labs, retailers) needs us to work together but it just feels impossible to get folks to play nice with each other.
How the F did email come to actually work across vendors?
- danpalmer 5y agoIt seems that there are two separate problems here: 1) States aren't valuing this above the closed source tracking solutions. 2) Some states aren't actively looking for a new solution (having one in place already). Unfortunately both of these are hard problems to solve, and have almost nothing to do with technology (which it sounds like is your area of expertise). > we assume that everyone knows distributed/federated systems are a good design goal This sort of assumption is sadly not true, at least from what I've seen. I'm in the UK and we have the Government Digital Service. They're pretty much one of the best government IT services departments in the world, 18F was modelled on them and they train other governments to set up equivalent programmes. GDS finds this hard! That's one centralised organisation, with wide veto power, and loads of deep tech/policy understanding that means they do value things like distributed/federated systems. Despite this, and while they've managed to overhaul the UK govt's IT services, they haven't substantially overhauled the open data scene. Even standards like Gov.UK Verify (distributed/federated identity verification) hasn't really caught on as they hoped after ~8 years. If arguably the best placed organisation to roll this sort of thing out struggles to do it from inside a government, then I'm not sure that a tech-focused non-governmental organisation is going to manage this without very significant leverage. That's what those existing tracking solutions probably do – they lobby. They'll spend money on lobbying (marketing) and sell contracts. --- I'm sorry this is such a negative answer, I'm all for open source interop protocols, but I guess I'm suggesting that you need to view it from a different perspective. Assume that they don't care about it being open-source or federated. Assume that the closed source competitors are lobbying and doing all they can to legally bribe decision makers. Assume that even if you were actual government employees implementing this, that it would be an uphill battle. Now, what can be done from those assumptions? Some things that come to mind are – grassroots organisation, getting everyone else onboard so that the incumbent tracking is essentially pointless? Maybe try for some legal challenge on the grounds of competition? Maybe hire someone who has sold the incumbent contracts to help you "sell" this in the tender process as if it were an existing solution. I wish you all the best of luck, I'd love to see more open-source interop protocols for everything!
- openthc 5y ago> I'm sorry this is such a negative answer Don't be; I'm here for frank feedback and appreciate yours.