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

(we assume) that everyone knows distributed/federated systems are a good design goal

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

You keep mentioning things such as "the industry needs us to work together", but you never explain why. What benefit would companies who you call competitors get from being interoperable with you? Perhaps this comes simply from my unfamiliarity with the space you work in, but if anything then lock-in is often useful from a business perspective. (It is not useful from the user perspective, but I don't think that's too relevant to convincing other companies unless legislation happens.) In short, after reading all of the above, I still don't see why anyone would want to put in the effort to conform to your spec. Perhaps the people you're trying to convince are in a similar situation?

Write tools and libraries for them, document them, and maintain them. You need to make it easier to implement your interop than it is to use their own tools.

You need to start with the question of who _benefits_ from using your protocol. You think that it's "your competitors", by which I read other software vendors that are providing solutions to the cannabis industry. Hot take: Your solution isn't helping other software vendors, it's making more work for them. Working with a published (and probably over-designed) specification is _always_ going to be more work than just hacking some glue scripts together that solve the specific issue you need to solve right now.

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.

1-You have to put it in their self-interest, and explain it to them that way. What else can you do to make it in their own interest?

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.

Most data interchange specs that actually get used come from suppliers that already have a huge share of the market, or from a widely recognized standards body. Since you aren't either, how about trying to start an independent org on which you will be one of many board members to promote interop itself, not necessarily your protocol. A long road to be sure but also somewhat less intractible.

@dang it would be cool if links in Ask HN posts were actually links.

why use this instead of open standards that exist?

full disclosure I’m the primary author of OpenCannabis — the other open standard for the legal industry.

edit: learn more @ https://GitHub.com/OpenCannabis

You have to be the market leader, then the other 149 other software providers will implement it in order to take part of your market.

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).

John O'Nolan from Ghost was a guest on indie hackers recently. His approach to Ghost speaks pretty directly to the question you're asking here.

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.

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 the table names in a SQL query. 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

I would think of this like a normal customer development / lean startup problem.

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.

You need to provide developers with a real advantage in excess of the disadvantages of your protocol (everything has disadvantages) and the cost and pain of incorporating it.

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.

- pay them to adopt it. - get their customers to refuse to pay them unless they adopt it.

The big problem here is that it sounds like you took an "if I build it they will come" approach, which is just never viable for this type of thing.

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.

one way or another, get their customers to ask for it.

It 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!

Blockchain solves this (not kidding).