Ask HN: How to get compeitors to use our open source interop-prototcol?
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?
53 comments
[ 4.7 ms ] story [ 106 ms ] threadCannabis is heavily regulated, each tree, each lot, each lab-result, each everything in the system is required to have a unique identifier on it; it's a government required compliance thing. Cannabis businesses MUST do this.
But then BusinessA sends to BusinessB for toll-processing the plant-matter into oil. The lots, and associated data must be sent from one system to the others -- so they are both reporting the same identifiers (it's how the government is supposed to track inversion/diversion). And once BusinessB finishes processing, they may test it at a lab (BusinessC). Then BusinessB sells/returns some of the material back to BusinessA. A and B need the lab result data from C (it's like 170 data points, and a (signed) PDF). And when A and B package that material and sell to BusinessD (retailer) then the lot identifiers, product/package details, lab results, PDF, etc all need to be sent.
All that happens "seamlessly" (it's actually not, but a longer post) -- so for A,B,C and D it mostly "just works". And at the moment that "just works" bridge in Washington is going away. It's why we've had renewed interest in our project -- by BusinessA,B,C,D,etc -- even when they don't use our solutions. They are using competitors software, calling me asking if we've reach out to VendorM (we have, many times), then tell me they haven't discussed with their software provider, but then setup a meeting with businesses using a mix of the software and staff from the providers and those business owners say: "the fuck man, we shouldn't even be having this conversation; you guys should have figured this shit out already." (actual quote).
And at those meetings the other software vendors couldn't agree to agree; hadn't even looked at our proposal and could hardly even commit to agreeing that, in theory, interop was a generally good idea.
Without a standard developed by an industry working group controlled jointly, it won’t happen. Otherwise you’re just making it easier for customers to avoid platform lock-in — the same lock-in that platform vendors are trying to encourage. Of course they want no part of this; I wouldn’t either. Even with a working group, it’s not clear that this technical problem is a business problem for the software vendors.
The retort, to the business owners, is that this is figuring it out. Ask them if Cannabis is legal yet, ask them if they heard about the huge drug bust last week (last week!) in Alameda that the cops are all proud of themselves for. Ask them if they're business owners, who are willing to roll up their sleeves and do some actual work, or if they're just lazy stoners who thought they could get rich and didn't have to do any real work.
You've heard the story of the first shopping carts, I presume, and then also the black art of pricing products.
Here's an idea from that - speak the language of business people - charge money for the interop, then invite the people that actually do the work to meetings, and don't invite the business owners. (I mean, sell it to the business owners as this is what they're paying their people for, so they don't have to go to these kinds of boring meetings.)
Your choices are to force VendorM into taking your calls somehow - through regular business channels (which it sounds like you have), but also through regular irregular channels. Who do you know at VendorM, where do they like to play golf/etc. Amass a giant pile of capital and buy out VendorM and all their customers. I'll bet you can get them on the phone then.
The retort, to the business owners, is that this is figuring it out. Ask them if Cannabis is legal yet, ask them if they heard about the huge drug bust last week (last week!) in Alameda that the cops are all proud of themselves for. Ask them if they're business owners, who are willing to roll up their sleeves and do some actual work, or if they're just lazy stoners who thought they could get rich and didn't have to do any real work.
You've heard the story of the first shopping carts, I presume, and then also the black art of pricing products.
Speak the language of business people - charge money for the interop, then invite the people that actually do the work to meetings, and don't invite the business owners. (I mean, sell it to the business owners as this is what they're paying their people for, so they don't have to go to these kinds of boring meetings.)
If you want to be in the interop standards business, put some hubris in it. Market your service, loudly, proclaiming that you're the one true standard for the industry, charge businesses a pile of money. Let business owners's employees discover that the underlying spec is free and sell that to their boss as being worth their time. If enough customers ask VendorM if they've implemented the spec yet, they'll make time.
Your choices are to force VendorM into taking your calls somehow - through regular business channels (which it sounds like you have), but also through regular irregular channels. Who do you know at VendorM, where do they like to play golf/etc. Amass a giant pile of capital and buy out VendorM and all their customers. I'll bet you can get them on the phone then.
The retort, to the business owners, is that this is figuring it out. Ask them if Cannabis is legal yet, ask them if they heard about the huge drug bust last week (last week!) in Alameda that the cops are all proud of themselves for. Ask them if they're business owners, who are willing to roll up their sleeves and do some actual work, or if they're just lazy stoners who thought they could get rich and didn't have to do any real work.
You've heard the story of the first shopping carts, I presume, and then also the black art of pricing products.
Speak the language of business people - charge money for the interop, then invite the people that actually do the work to meetings, and don't invite the business owners. (I mean, sell it to the business owners as this is what they're paying their people for, so they don't have to go to these kinds of boring meetings.)
If you want to be in the interop standards business, put some hubris in it. Market your service, loudly, proclaiming that you're the one true standard for the industry, charge businesses a pile of money. Let business owners's employees discover that the underlying spec is free and sell that to their boss as being worth their time. If enough customers ask VendorM if they've implemented the spec yet, they'll make time. Until then... hey, does photoshop open .XCF files created by GIMP yet?
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!
Don't be; I'm here for frank feedback and appreciate yours.
The reality is that because no one is using this protocol, your pitch is a really bad one for anyone you're pitching to - you think they should spend the time and effort to use your protocol, and what will they get for their effort? Nothing. No one else is using it, so they'll be implementing an interoperability protocol that doesn't actually make them interoperable with anyone else. Why would anyone ever do that? Why wouldn't they wait and see if others adopt it first?
This whole post honestly feels very self-centered - particularly "re-explain how common-data-model helps us (why are we explaing this to CTOs and techinical founders?)". You have to explain it because you're asking them to do work. They get to ask you whatever they want, as many times as they want, because you're not presently offering any value whatsoever. You need to stop assuming that everyone else shares beliefs about your protocol that are obvious to you, the person who spent a lot of time and effort planning and building it.
Instead, put yourself in their shoes - what would make this attractive to them? Since we're talking about interoperability, clearly if there were a lot of other folks using it, that would be a selling point. You obviously can't offer that, but you could try to get soft commitments that companies would use it if a critical mass of other companies did too - if you get enough of those commitments, you can then show that there's potential value.
You really need to find someone who understands sales or business development to guide you here. It sounds like you built this with no real input from anyone, and now you're taking it to companies, explaining what it does and getting frustrated that they aren't responding positively.
The one thing that it doesn't seem that you're doing at all in those meetings is asking questions. Why are you on HN asking what you're missing and what it would take to get people to sue your protocol?
Ask the people who you want to use it! When you're in those meetings, you should be asking people what would make this attractive to them and what would incentivize them to implement it. What you're doing right now is selling, and the way that you sell someone something is by understanding what problems they're facing and providing them a solution to those problems. The first step in that is asking questions - otherwise you're the car salesman trying to sell a guy a sports car because you think sports cars are neat, and you never bothered to find out that he's looking for something to take his five kids to their sports practices.
If you're serious about making this work, I really recommend finding someone with business development experience to help you out - if you don't, you're just going to keep spinning your wheels until the folks you're trying to convince just don't want to spend more time dealing with you. I know folks on HN are often deeply scornful of BD, but this is exactly what it's about - understanding the needs of the folks you want to work with and brokering deals that are attractive to them.
There is a small number which is but yes, that hardly visible.
> Why are you on HN asking what you're missing
It's a good channel for this type of feedback.
> Ask the people who you want to use it..
We've been working in this industry since 2014 and have talked with literally 1000s of cannabis licensees; they know they need this (regulatory obligation); when they have Metrc they hate it; and it doesn't carry the proper data forward; and folks get stuck with teidous manual data entry -- so they feel the pain every day. The customers we have on our hosted solution, one of our big selling points is trying to build the industry together with open specifications. When Washington state had another issue with their cannabis software in late 2017, an industry assocation made efforts to introduce this open specification at that time. Some of our competitors (not in Washington) have even purchased consulting time from us to talk about general system design for cannabis industry software -- it's where we also got some of that feedback for the existing models.
So, we are, and have been, and continue to be activily engaged in conversations with industry participants many of whom actively find us to bring their problems to; and we turn those into the virtious cycle customer feedback loop.
I know it's common in the "tech space" to have folks put the cart in front of the horse. I think our case does NOT do that; since 2014 a profitable customer driven company; starting the open-source efforts in 2016 in a constant, customer engaged method. It's why our competitors and our competitors clients literally call us for help.
Did you get their contact info?
If you kept them informed of all options in the space I'm sure they wouldn't unsubscribe from your thrice-yearly newsletter.
If you're not working to build the (online) community you want to see, it won't magically appear by itself. I see you've published roughly 1 blog post a month since May and that's good, but nobody is going to read it unless you're emailing it to them. Obviously you do have to provide real value vs. being considered spam though... the first email should be knock-your-socks-off amazing (again emphasizing: give them value for themselves, not as much pleading your own cause), get several people to review it first. You probably need to get testimonials involved on the website, are you saving businesses money?
Edit: You didn't share your most recent blog post on Twitter (500+ followers, nice!), and the most recent post needs more editing ("The permitted values are" ... followed by nothing.) Also, you might want to target a slightly wider audience... I don't know enough to know whether barely interested potential community members on the east coast would know "LCB CCRS" without acronym expansion.
It looks like you could really lean into your Twitter. The other social media accounts give the appearance of neglect... if you don't have time, maybe use the others to point to the primary tool? Social media marketing should be scheduled (I guess until there's so much that you wind up trying to appear random), and if it's not going to be scheduled that's probably worth being up front about too.
Final Edit, I Promise: I was going to email you a heads-up in case you've moved on from this discussion, but decided it wasn't worth it... so there's an example of usefulness vs. spam vs. content going nowhere. Hope this is helpful if you ever see it.
You need a document format that each party can produce and consume, a method of sending/receiving them (something email-ish), and optionally an API to access them.
A distributed database is potentially a way to implement this idea: you get a data format, a method of transferring data, and an access protocol but that's so much more complicated than just a normal web API and even if you went this route the model for consensus is off in the case of conflicts.
E: it's MIT but, still.
Do they? Are they? Maybe you need to check if anyone else in this industry thinks this. If they don’t then you have to convince them that it’s a good idea, AND that your product is the solution to it.
You say “many of the vendors have APIs”; will switching to your product solve the problem of interfacing with them? Is this a problem anyone is having? Perhaps you can push adoption of your own API by making a product that talks to all these different closed APIs on the back end, and only requires its users to learn your API to talk with all of them.
Perhaps you should read the history of email. Wikipedia’s article on it starts by noting that it took fifty years for the current suite of smtp/pop/imap to become the standard. https://en.wikipedia.org/wiki/History_of_email
oh shit.
edit: we also made this: https://github.com/openthc/bong - Basic Object Normalization Gateway -- but it's like "draft" quality.
Really looking at your other answers: the industry does seem to be realizing it needs your unified API, and you’re in there getting hired to implement it. You are doing the work, and the only real problem is that you think it should take a lot less than fifty years.
If you take email as a model, your future career path probably includes forming a weed standards organization, issuing a lot of weed standards RFCs, and helping people implement them.
lol
full disclosure I’m the primary author of OpenCannabis — the other open standard for the legal industry.
edit: learn more @ https://GitHub.com/OpenCannabis
Open standards are great. We’ve got some significant buy in. But fracturing this into multiple specs has a risk of making it worse instead of better.
Also, your site https://opencannabis.info/ is offline.
edit: I see, you used to be BloomBox which looks like it died; perhaps that is how we missed each other.
all of the latest collaboration is happening here: https://github.com/CookiesCo/OpenCannabis
I had also been thinking that way and got the same reaction from the marketplace when this was first proposed in 2014.
Since then, working on point solutions which solve real problems for market actors has been the main strategy and that has worked really well. There are circumstances where cannabis companies must collaborate, but they aren't every circumstance. Adopting someone else's datamodel wholesale feels, to an innovative market player, like an abdication of their duty to understand their own product.
So, instead of replacing things, we add now, and adopt and include specifications that "just work" or have become defacto standards.
2-You have to demonstrate social proof of your momentum. Show who has recently joined, and use that to show people are rallying around it. Everyone goes where everyone goes.
3-Set it up so it isn't clearly "your" solution so they de-risk being at the mercy of a competitor. Open source, but also run by a foundation, not just you.
Is there anyone other than your company using this API? If not, it might make sense to find a single "customer" and make sure the API solves tons of problems for them. If you cannot get first adopter, iterate on the product/API until you can create something that a customer loves.
It sounds like people don't see strong enough value in being the early adopters of these APIs. You might need to iterate on API/product until they do.
No, the beneficiaries of your standard are the actual farmers, labs, and retailers -- in other words, your competitors' customers. But how do they benefit? Your standard won't make their software _cheaper_, at least not in the short term (see the point above). There are a few situations where these standards help software consumers. First, it can make migrating from one software vendor to another (relatively) easy, as the data can be exported from one system in a format the other can _theoretically_ ingest from. Pro tip: it never works this seamlessly in practice. The other primary usecase is where the consumer wants to incorporate several different software products in a modular fashion. If you don't already have a software ecosystem like this for your industry, this will be a chicken-and-egg problem. You're asking non-technical consumers to demand something from their vendors that doesn't currently provide value to them.
Good luck.
Yes, this has been our entire focus.
> hacking some glue scripts together
We're talking about, literally, two simple JSON data models and some specifications in YAML. We don't have some mature venture-funded thing -- we have a farmer funded thing that's basically glue and some zip-ties.
More power to you if it is this simple. Just bear in mind that while the structure is probably a good fit for the data model in your database, it's probably not such a good fit for anyone else, so other vendors probably won't see it as quite so 'simple'.
Another benefit of a standard like this is that when it comes to interoperability between two companies is that it splits up the role of who has to do the hard work to build the integration. Every vendor want's to point the finger at the other guy and say 'it's his problem'. If there's a standard, it's harder to pass off these dev costs onto others.
Especially since this is your standard (and, presumably, you don't have to do more work to support it) your call for your peers to support the standard can come across as sneaky way of passing off the work of integration to them.
Um, actually we made some not optimial choices with our initial app-data schema and working with other vendors got us to this one. And also, yes, because we've used it for integration in a few places before, there is less work for us to currently do. We have also offered to help other providers wherein we would be spending our own cash-time for a mutual benefit.
One (costly) thing I learned a couple times as an entrepreneur is that it's almost impossible for a small company to make a market but they can sometimes move a market. In the same way, you might not be able to make the standard (the fact that you refer to it as "our OSS interop protocol" is telling) but you might be able to coordinate an industry group that starts with something small and grows it to what you'd like it to be.
Warning: This takes an extraordinary amount of time (I've been part of RFCs that took 4-5 years for complex protocols).
OUR as in the Royal OUR: my team + some small but visible external contributors + some external non-visible contributors + some businesses paying to improve the model + some sending direct email PRs. I'm not sure what other word to use to describe a fledgling community that I'm part of besides "our".
https://share.transistor.fm/s/957e541c
The other suggestion is I would try to find a small place to start. Of the different parts of the industry who is feeling the most pain from these problems? What is the smallest piece of the project you could focus on delivers immediate value to that group? Something that you can iterate on.
Interop alone may not be enough at this point in time -- the pain of lacking it may not be high enough to overcome intertia.
Perhaps one way is to provide libraries that not only implement your protocol but also solve some immediate pain point developers have.
[0] https://www.splitgraph.com