4 ms·

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

by andjd 5y ago

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.

openthc 5y ago
> beneficiaries of your standard are the actual farmers, labs, and retailers 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.
- andjd 5y ago
  > two simple JSON data models and some specifications in YAML 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.
  - openthc 5y ago
    > structure is probably a good fit for the data model in your database 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.

by andjd 5y ago

openthc 5y ago

> beneficiaries of your standard are the actual farmers, labs, and retailers 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.

andjd 5y ago
> two simple JSON data models and some specifications in YAML 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.
- openthc 5y ago
  > structure is probably a good fit for the data model in your database 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.