SmartThings Platform Developers Perspective

I disagree on the app store concept. IAP (in app purchases) would be a bad way to go. First the 30% cut to the provider, then what split to developer / ST?

A better way would be for ST to build a back end where developers can sell, support and track their customers, using the same tools (potentially) that ST has.

I see the biggest issues facing community developers from monetizing their solutions are these:

-Support
-Revenue
-Access

Support
ST has already shown an inability to handle a flood of customer issues. Trying to support a custom SmartApp or DeviceType as a community developer is damn near impossible. We get ZERO information beyond what every other customer gets.

What Needs to Be Done?
Allow a certified Developer program, in which we can get access to the ticket system, assign and handle support issues as if we were integrated into ST.
Provide a separate area, password protected, forums (like these) that internal and developer communications can be shared, which is not meant for public view.
Weekly Developer calls with actual representation from internal teams inside ST, not just a community manager

Revenue
Allow a SmartApp Store to exist outside the App ecosystem. Avoid the 30% cut by selling the SmartApps and DeviceTypes at an account level. Nothing has to be bound to the mobile app.
Allow other methods of SmartApp install to continue and expand, ala how SmartTiles and others use OAUTH and such to install without being approved.
Allow encryption in IDE so that people can buy a copy of a community code, without the ability to encrypt. Think binary / executable. Copy the encrypted code into IDE, IDE decodes it, ST would always have the public keys, so support and others would always be able to see the code, just like today.

Access
Do real beta testing for developers. All certified developers are automatically beta testers. Offer wholesale pricing on sensors and such available through SmartThings store to equip themselves and test with variety of products
Offer a testing lab in PA and Minneapolis where developers can test their SmartApps in a lab, via reservation system
Weekly developer and engineering teams calls. Rotate each group every week so no more then once a month per team.
Share access to ticket system, so developers can support their solutions within the same ST system
Share internal bug tracking with developers so they know existing issues and coming fixes.
Private access to discussion forums outside of public view.
Certification process and training for new developers

Just my two cents, but if ST really wants to get behind community developers, the above would go a long way to help further the cause.

4 Likes

I think what you are proposing is feasible, but feel that the comprehensive requirements you describe won’t be implemented for a very very long time. A “basic” store, sure, but it will suffer without your wise corequisites.

2 Likes

I’m not sure there is enough critical mass to support any kind of store. I’m not sure what if anything I’d being willing to pay for. SmartTiles comes closest, but it’s rare. So if it’s as sparse as I find it, why can’t @625alex just charge what he wants on his own website, and be done with it? As you say, what @pstuart suggests won’t happen in this universe, unless I’m confused about which one I’m in at the moment. :grinning:

1 Like

I fully agree with this idea and I would suggest paying a fee to become a “certified developer” if that would offset the cost to build out the tool chain.

There are certain ideological questions that still need to be answered before a real conversation about the marketplace can take place.

###Device Types
How can someone like @yvesracine officially charge for his device types? Given that there is an “Official” device type for the Ecobee3 thermostat, it’s unlikely that his would ever be approved even though his device type has much richer integration than that of the official release. What happens if a developer does manage to get his or her device type approved and then some time later the vendor of the device decides that it will take over the integration once the interest in the platform has been established?

##SmartApps & Automations
I see no issue with @625alex selling his app on his website, but again this is an ideological issue not a technical one. Major changes need to happen to the platform to allow the kind of rich multimedia within a SmartApp that SmartTiles provides.

SmartTiles really goes beyond a basic SmartApp and is really more of a solutions module. Given better access to the API, this would definitely be one of the more popular paid apps in the marketplace.

###This is the ultimate ideological question

Is SmartThings going to be a developer driven platform or a platform that allows some very constrained developer contribution.

If it’s the latter, then we are already most of the way there. SmartThings is already a platform that allows you to write your own SmartApps or extend the existing ones. SmartThings currently approves newly created SmartApps under very narrow conditions chief among them is that developers cannot duplicate existing solutions.

3 Likes

@jody.albritton,

I hope that you’re wrong… :smiley: The way I see it, even if there is an official Ecobee3 device type one day (still waiting…), I think mine will always bring tremendeous value to anybody that will purchase it, because it’s not only a device handler, it’s a whole ecosystem of smartapps that I can deliver which brings a greater value…

For example, I’m currently testing my ecobee integration with smart vents…

And the way I understand the certification process is that ST will accept custom device handlers that bring more functionalities than the stock ones…
Regards.

2 Likes

So, you’re saying that in order for me to “sell”, I will have to pay first? So, what’s the potential audience are we talking about at this moment? If we’re talking about millions of users, then it’s not a problem to enforce this.

The way it is right now, is an advantage to ST’s growth. Users don’t have to pay anything extra since developers bears the cost by giving out solutions for free. If a paywall is implemented, users might not like it at all and this would potentially drive away customers.

Just my 2 cents.

2 Likes

@Tyler has expressed that he does not forsee any likelihood for ST to offer multiple official Device Type Handler options for the same physical device. This essentially cripples the Marketplace for Device Handlers, as once one is approved, getting it replaced by a competitor’s development effort is a big hurdle.

I don’t understand why we can’t come up with a creative way to avoid this constraint. The market for diverse richly creative or efficient Device Handlers is not insignificant.

First of all I estimate there are over 100,000 hubs in circulation. That is enough of a target audience for me to consider jumping in.

However, I need a model that can monetize my efforts.

This is the critical issue facing all the community developers. We need a way to get paid or we lose interest or get hired away by someone who will pay us for our knowledge.

Why can’t ST have a certified developer program, complete with required onsite or virtual training, actual documentation, knowledge base, engineer level support, etc.

Instead, look what has happened in the last year. 180 people hired by ST, doing what?

Pluck the best from the community, crank out “built in” solutions based on resources the community doesn’t have access to and prove to the upper management and Samsung that you can do it better internally.

Here in lies the rub.

This community built SmartThings from a kickstarter to acquisition. This community has to fight for its future. This community only represents 1% of the total SmartThings install base. Most users just want it to work out of the box, they don’t want to learn how to code.

What is at stake is the very critical role the community and its developers will play ultimately in the future of ST. Will ST open up its doors and allow community developers in, or will the continue to separate themselves from the community, continuing to treat them like any other customer.

This is the heart of the matter.

Community Developers who give back, feedback, code, ideas, concepts, etc. should not be the same as a customer complaining about a back-ordered hub on Amazon.

The time has come to separate out the developers from the users. Those that are serious and want to be developers should apply and go through the training process and get in to this proposed walled space.

As for how difficult something like this is to do?

It’s a difficult process, but it can be done in under 6 months, tops. Most of it is just ST buy in to get behind the idea. Set up virtual classrooms, knowledge bases, training programs, etc. It needs a champion. It needs someone who says, absolutely, just do it.

Unfortunately, this is exactly the same thing I said over a year ago. It was met with, yes, this is what we want to do. Yet here we are, a year later and still talking about it and really nothing to show for it. At least from where I sit. I hope I am wrong…

I really want this to happen. I just want to see that ST does to. (and actually do actions more then words)

Just my two cents…

6 Likes

You are right. Just like most other companies in this space, SmartThings could put up a Developer site, with logins, etc. Just like Amazon does. Amazon doesn’t filter who can be a developer, and neither should ST. But once you are a developer, you gain access to things that consumers don’t have access to and don’t care about. Separate the IDE. Provide a dirt simple mechanism to share custom apps here in the Community to ordinary users, so they don’t have to use the IDE to use the apps.

2 Likes

Exactly. ST treats Community developers the same as ordinary users. This is the crux of the issue. There needs to be separation. And it can’t just be in the form of hiring community devs and putting them behind glass walls.

This needs to be done now. It can and should be. The only thing stopping them are either resources or politics. The resources exist here in the community to do it from our end. So the ball is in ST’s court…

2 Likes

However they do it, I just sincerely hope that freely giving device types and smartapps doesn’t become “downgraded.” I don’t want to incur any expenses, nor suffer any disadvantages, when freely giving my work. For me, this is a hobby and form of entertainment. The moment I accept money for anything, it becomes a job.

[quote=“yvesracine, post:25, topic:21842”]
And the way I understand the certification process is that ST will accept custom device handlers that bring more functionalities than the stock ones.
[/quote]Do you have any reference for this understanding? My experience so far is that they just don’t accept custom device handlers PERIOD. If/when they do, my impression is that they will avoid accepting anything that becomes redundant with existing device types.

1 Like

Excusez moi, but who cares about SDP? I need no frigging certificate to write software for Linux, Mac, Windows, Android, iOS or any other open platform. What makes ST so special that it would justify certification? Samsung publicly committed to keeping SmartThings open for everyone, not an exclusive club of “certified developers”.

The time has come to separate out the developers from the users.

And how do you suggest to do that? By paying a certification fee for the privilege to call yourself a “developer”? Any “user” can become a developer simply by writing code. That’s the true power of an open platform.

4 Likes

Nope. I said I think if you want to become a certified developer I would suggest paying a fee. Not that paying to be an “official” developer is unprecedented, it costs 99 USD to become an official apple developer. Microsoft charges for some of it’s developer programs. Learning and coding for yourself should always be free.

1 Like

@garyd9, during a developers call about app submission (I think it was Feb 12) I asked ST how long it would take to certify my custom Neurio device.

Somebody from ST (not Tyler) told me at that point that would take about 1 month given the backlog…

@Tyler or @tslagle13, could someone from ST validate this statement once for all:
can ST community developers submit custom device types, and even some that bring
more functionalities than the stock ones (such as My Ecobee Device)?

I’d like an answer ASAP as I’m currently starting to work on a mega device type that will take several weeks (and months with testing) to complete.

The cloud-to-cloud integration device handlers that I’ve coded so far involves a lot of work because I need first to understand the partners’ data model, and then their custom APIs.

So, I’d appreciate if somebody from ST would say to me: eh, all the work you’ve been doing will never be certified, nor it will take advantage of the Hub V2 platform with its local processing…

That would be a wake up call for me, because for the moment, I’m just dreaming like the others.

Thnx for your support.

1 Like

I think this is an important question but the answers are probably very complicated, hence the reason we have not seen anything concrete in this area.

I alluded to a scenario in my previous post where things could be very untenable.

Imagine looking through the marketplace to find out if a device you own is supported, not only is it supported but there are no less than five versions of support. Which one do you use? If you are an end user and one costs money while another is free, which would you choose? Who do you call when the device does not work as it should?

Looking at it through this lens, it makes sense to only have one official device type. The end users want a simple plug and play experience. I am not sure how that gets reconciled.

The other scenario; there is no official device type but there are users willing to pay to get the device integrated even though the vendor is unwilling to provide that support. This would be a perfect area for some kind of bounty board.

A user or users pledge support to the developer(s) that creates the integration. The developer creates the integration and gets paid. Once the vendor sees that there is enough demand for their product to integrate with ST, the vendor could take the solution and build on it or let it remain a community driven project.

Some of these integrations are non-trivial as others have pointed out. Many weeks or months of development time go into some of these solutions and it’s not at all clear that there is a path to get compensated for this.

Hi @jody.albritton ,

The issue you raised above has already been addressed in many appstores: based on some ratings, end users will make the right decision according to their own criteria…It’s the law of the market (based on supply and demand).

For example, on Google play, I can find many versions of the VLC client app: some of them are free and some of them ask for a fee. Usually, the best ones are the most expensive because they bring more features or they are more robust.

So, I was expecting the same for the ST marketspace.

Another argument in favor of custom device types (or handlers): as I said earlier, I’m currently starting to work on a custom device type for a mature partner with millions of subscribers.

To be conservative, let’s say that only 1% of the total customer base will be interested in a cloud-to-cloud integration with SmartThings, that’s still tens of thousands of potential new ST subscribers!!

So, I strongly believe that community developers like us have already brought many new subscribers to ST and can draw even more as IoT is becoming more mature.

My 2 cents.

1 Like

(I’m not even sure what Neurio is… but…) Was that device ever certified? My reason for asking is that about 8 months ago (Jan of this year) I took ST’s own z-wave garage door opener and modified it so that it’d work with ST’s own “doors and locks” module… and submitted it back to ST. It was a trivial change, but it’s been sitting there completely un-reviewed since then. (As far as I can tell, ST’s own garage door opener never changed either.) So, if they HAVE reviewed device types, that would lead me to a different conclusion than if they’ve just ignored all of them.

[quote=“yvesracine, post:34, topic:21842”]
I’d like an answer ASAP as I’m currently starting to work on a mega device type that will take several weeks (and months with testing) to complete
[/quote]Be careful with that. ST is really good about making promises to developers and never delivering… Personally, I wouldn’t put much stock in any promises made by them anymore; especially if this is a serious effort on your part that you would regret if their promises aren’t fulfilled.

1 Like

Hi Gary,

I don’t want to get into a lot of specifics about the www.neur.io case, but this is a typical concrete case of the potential role of community developers like us and the need for more empowerment…

At the beginning of this year, I was approached by neur.io to develop a device handler for them as they wanted a tight integration with ST and could not find any internal ST resources to do it.

So, at that time, I decided to do it because in any case I wanted such a device in my house (power & energy meters for the whole house and appliances) …

I then worked on the device type and completed my piece of work in May. However, there is still a bug in the Android UI since 1.7 that prevents me to submit the device handler for its certification.

You can imagine my partner’s (neur.io) reaction when they found out that this ST UI issue is still pending since May!!

Not only they could not have internal ST resources to do their integration, but the ST platform itself prevents them to complete the integration.

(See my posts in this thread about the UI issue: Android App (1.7) - #7 by April)

In brief, the ticket (#101078) is still open since May 9th…

So, this case reveals the fact that community developers need some kind of empowerment; otherwise, we’ll always end up being stuck between the limited ST resources (at engineering amongst others) and our own ST customers.

My 2 cents.

3 Likes

Did you only get this out of what I posted?

Fine, a badge, something that opts you in as a developer and gives you the benefits as such. The costs of training need to be absorbed somehow, but that would be up to the developer.

How would a developer program “close” the platform, if anyone can join it and develop?

I am just calling for the immediate separation of users and developers and a renewed focus on the developers to move this open platform forward.

Not all users will be developers.

2 Likes

Speaking as someone who doesn’t write code these days, I would respectfully disagree with the above.

I think the Phillips Hues provide an excellent counterexample. They are designed for plug-and-play. They are sold to mass market consumers.

If you go to the app store, there are many different Hue apps available. It’s up to the developers to explain what differentiates theirs, and what would make it worth buying.

If the developer can’t make a clear case for their app, it won’t sell.

Consumers do not appear to be confused by the fact that there are third-party apps as well as the official app.

Any individual app which seems confusing or redundant just gets ignored.

I would expect the same thing to be true of device handlers. Tell me why I would want yours instead of the official one, and I’ll consider it.

Choice is a good thing. :sunglasses:

2 Likes