I'd like to give my vote to a formal "app/driver adoption process" whereby excellent community-driven projects like this eventually make their way into native integrations.
Hear me through: I've watched innumerable codebases rise through the ranks from an avid DIY coder's basement, to a 0.1 release to his forum friends, then expanding via github and a flurry of 1.x fanfare, only to get mired in a 2.0.1 stasis when (a) the original author leaves, or (b) changes to hub firmware hinder progress, or (c) well-meaning users fork the app to add in features for themselves, etc.
I would just love to see Hubitat be among the first HA companies to take the App Marketplace concept seriously enough that good apps can, at some point, perhaps by vote of the community members – and of course with the express permission of the original author(s) – be taken aboard as an "official" (stock) plug-in. This could benefit the dev, sure, with a little pocket change. But it would also guarantee the far more important principle of sustainability while thwarting code rot long-term.
Let's face it: Things change. Platforms move from open RESTful API's to un/pw to OAuth to who-knows-what in the future, making upkeep a hassle. Whereas apps under the company umbrella stand a stronger chance of keeping with the times as consumers demand evolution. In turn, that evolution drives wider adoption by prospective Hubitat customers. Which allows the suits to monetize something that might have fallen fallow otherwise.
Thoughts?
P.S. In the meantime, I can't wait to try the GCS app***. We had a similar 3rd party plug-in back on the Vera platform, and I dare say it worked like a charm, but never really reached a wide audience. Now, 10+ years later, the author (like so many former Vera users) has moved on.
[***NOTE: Originally posted in a thread about the Google Calendar app]
We have been known to do this. SharpTools was the first, and also ActionTiles. We don't want to do an actual App Marketplace for several reasons. If the author of a popular app approached us, we'd certainly give it due consideration.
Thanks for clarifying @bravenel and let me please add that I LOVE the work you guys have done on Hubitat so far. Count me among your most ardent fans (watch every YouTube video, read all the docs, try out all the features, etc.), as I've enjoyed this breath of fresh air coming from the dank and stale depths of the once-revered MiCasaVerde.
Guess you could say I'm itching never to see another company miss all those golden opportunities. I won't go on about one of your erstwhile competitors, since that is bad form, but suffice to say the key to success has been and always will be keeping your customers happy (and, frankly, keeping your customers... period).
You guys are top dogs as far as I'm concerned, so glad to be aboard!
I actually see the opposite being a possibility. Instead of a community of dozens or hundreds of engineers each supporting 2-3 integrations, you now have a small company of maybe 5-6 engineers trying to maintain 200-300 integrations. That doesn't seem feasible for a small team to maintain. For what it's worth, I don't have any interest in having my apps built into Hubitat. It's not about the money, it's about the fact that I built them for my needs first and foremost and I like being able to control their destiny. I think many app devs think similarly.
@dman2306 I happen to agree with you on all points. Perhaps the meaning of "adopt" got overstated in my OP. I didn't mean "take over" in the sense of who handles the codebase or feature set, but more of a collaboration.
On the corporate side, and given some of the company history I've now come to understand about the founding members, I can see why they too might shy away from this model. On the devs' side, I concur that some proprietary pushback natural, which is why the "adoption" process would be strictly opt-in. Maybe I should have called it "Co-parenting"?
Unstated in my OP is the sad fact that some of our elder coders may not be with us forever – many a Forum is riddled with "Where did XYZ go off to?" posts – or may suddenly find themselves without the time and financial resources to devote to keeping up their precious app.
I know, that's where Community normally steps in. But expert devs are considerably rare, and if my proposal were to breathe life into projects which might otherwise wither, or fail to gain the wide acceptance they deserve, then it's a win-win.
I'm also not trying to say, "There can only be one app of Type ABC and we should crown it the winner". But I am saying, if that winner has already been established and a large proportion of Hubitat's userbase has come to rely on "Type ABC 3.5 with Extra Type!" then a form of official blessing may be in order.
This is me, thinking aloud. Glad you laid out the flip side of that coin.
I get what you're saying, just not sure what the solution is.
There are definitely examples of this. Even worse there have been people who purposely deleted their apps in a fit of rage. There have also been times where manufacturers break things intentionally -- most of the integrations for HE and other smart home platforms are using APIs the manufacturers don't intend others, and sometimes actively prevent others, from trying to use.
In my opinion, where Hubitat and other commercial enterprises can help is by trying to reach out to some of these manufacturers and getting them to want to offer an official integration with Hubitat that they build because they want to have their devices reach a wider audience. Then you get something officially integrated and supported by the device manufacturer themselves. Just not sure Hubitat has a big enough userbase that manufacturers would care to do that?
