Is obfuscating going to kill the community?

First of all, this is not flamebait nor is it intended to spark a fire. That being said:

Looking at the release notes for the 2.3.0 build, the most striking item to my opinion was:

* Added an option to create user apps/drivers without exposing their source code.

So basically this opens the way to payed apps, as a developer can now hide his/her source code.
this is not what the Hubitat platform is all about to my opinion. I think the thing that is making Hubitat grow, is the fact that the community can create and share drivers, apps and ideas.
Obfuscating sourcecode is not helping the community, and therefor wil slow Hubitat's growth.

So I kind of wanted to hear the community's opinion on this.
Am I seeing ghosts here, or do share my concerns.

3 Likes

I think it's the way of the world. My take is it goes the way of Wordpress.

I share the assumption that it would allow for paid third-party apps, but I don't share your concern. Developers are already operating happily in the current environment where the code is visible, so I can't see that aspect changing. This change in the new release just provides options for those who may want to sell there services without fear of their IP being stolen. The two can co-exist.

5 Likes

It would also make the possibility of the hardware companies writing their own integrations more attractive.

2 Likes

If I had to guess, this would have been either a request or something they just wanted to do for one of their "Developers Plus" developers:

Developers in this group have signed agreements with Hubitat and are allowed to charge for their apps and drivers.

I can think of one in particular but won't bother naming names. :smiley: And it could still have just been something Hubitat wanted to do, perhaps to encourage more such developers who might prefer a closed-source integration for any reason, as @sburke781 hinted at above.

The idea doesn't seem totally odd to me--after all, most of the built-in drivers, plus the bulk of the platform itself--is closed-source. But the difference there is that I can count on support when I need it. I really don't see most community developers on here being likely to go this route. I could be wrong about that, but hope I'm not; again, my assumption is that this was done with the aforementioned group in mind, even if anyone can use it (though I think Hubitat has to put your URL in an allowlist first).

I don't plan on using any third-party apps or drivers that are closed source (and I don't plan on doing this with any of mine). I could see me making a rare exception for myself if they moved something like SharpTools or ActionTiles to be "community"-supplied instead of built-in (they're already closed, and the companies have enough of a reputation behind them for me to trust them). Otherwise, hard pass from me...but, again, I don't think (hope?) this will really end up being a big issue for most community code at all.

12 Likes

Have professional/paid apps does not eliminate free apps. I completely and strongly support this action by Hubitat.

1 Like

The reason we did this grew out of the need of a partner in Australia who installs hubs in people's homes, and has a legitimate need to keep his driver source code private. We are not in hot pursuit of paid apps.

24 Likes

I'm going to give a contrary view, although not far off... maybe just competing view vs contrary...

I'm speaking of HubConnect. The source was moved to a login server where the source was available to only those willing to create an ID. It was triggered by people borrowing the code (allowed) without attribution (not allowed). It was not JUST a HubConnect issue, but I know this story better than any others.

ProBundles will allow me to put a 'blind copy' of the code back in the public space while still retaining the login server that exposed the code, for those that need.

In other words, I feel BOTH is the correct answer for HubConnect. And yes, I know that the Age of HubConnect is dwindling, but the use cases do exist still.

4 Likes

In the end the community will decide if they want it or not.

I know there were a few apps from ST that people wanted ported over (cant remember the dev) but you had to pay to get access to the source and I don't think the dev wanted to port them over without some security. This could help get him here if people still have a want for them.

I liked having the open sourced code.

  1. I could see what it really does and get an idea of the effects it would have on my hub
  2. i could lear from looking at others code which was very valuable
  3. I could also see if it did anything out of the ordinary for security reasons.

If I don't like it, I just wont use it.

1 Like

I agree. Many developers do this essentially as a hobby and I’m not worried they’re all going to suddenly disappear behind a paywall.

3 Likes

Yep. I review each Community app before installing, and I only install from trusted, reputable developers.

4 Likes

Neither of which do we want to touch.

6 Likes

I have to laugh a bit - and likely no one will with me - but I'm me - Whats the definition of trusted? Reputable? Is Amazon? Is Heroku? Github? lol... please!

"Who watches the watchers?" - Enemy of the State

5 Likes

Threads like this often stray into declarations re: what Hubitat Inc. should do to grow, become more profitable, etc.

Respectfully, I think statements to that effect are always pointless. That’s simply because as customers, our opinions are majorly uninformed.

With this one change, how much do they stand to benefit from this new partnership with an Australian installer? No idea. None of us even knew that partnership existed til Bruce mentioned it.

I think we should keep our opinions focused on what we’d like to see happen as customers. If you have concerns or doubts about closed source vs. open source code, by all means please share them. But don’t conflate that with the notion they are making an unwise business decision.

2 Likes

This. A free community app that is closed off from from scrutiny should not expect widespread (or any) adoption.

I guess that's for each person to decide for themselves. You do that all the time when you install a new piece of software on your computer or phone.

If I have to pay for an app - a one time developer with no long term positive presence in the community or software development history is automatically suspect until proven otherwise.

Actually, if I were to install hubitat based systems for customers, the one thing I would rather have is the ability to lock out/hide access to specific hub administration features like adding devices/apps or new drivers/app code rather than simply keeping source code hidden. The last thing I would want are customers installing their own gear and calling me when something goes wrong with their mesh due to an incompatible device.

4 Likes

Doesn't it really depend on whether you are selling your customers a service or an installed hardware device?

Wouldn't you just security protect the hub?

For this particular partner, end customer access to the hub admin features is desired. What isn't desired is competitors' access to his code.

In the scenario where the end customer is locked out from the hub admin interface, protecting source isn't a relevant issue.

10 Likes

I have another question for you.

I always see the word 'free' ie The free 2.3.0 update adds...etc.

Does this mean at some point in time the 'free' is no longer going to be there and you will have to pay for updates, maybe other than security patches?

I have never spoken about "it must remain free". That is up to Hubitat inc.

My concern was that apps would go behind a payed wall.
I want to share my own code, so ppl can improve it as needed.

The whole reason I started this discussion, was that I have seen something simular win a competitor Honmey.
They launched a new hub, that basicly is a big array of antenna's but no local processing. This product would be launched besides there normal smart home hub. Nasty thing is, if you wanted to have the apps you have on your normal hub on that new hub, you needed to pay as a dev to Hubitat just to get your code to run on there hub.
I have seen allot of dev's run away from that platform after this action.

Me myself, I want Hubitat to grow, as I like the platform, and the way it works. That is why I have a payed subscription for remote admin and hub protect. I do not realy need them, but it will support Hubitat.

To my oppinion, there is a huge groth market in the EU for Hubitat. Just needs to be more compatible with EU versions of products, and more EU oriented adverts.