API
Web
The current system of building one’s own API through SmartApps gives one the ability to create a wide array of solutions, but it does not cover everything. I would like to see access to more of the “Core” API accessible to developers. SmartThings as a platform could grow and innovate much faster if the developer community were enlisted to create solutions to problems like dashboards and control panels. SmartThings the company cannot possibly build the client that is all things to everyone. Allow developers to fill in the gaps. Imagine solutions that are tailored to the elderly with large easily readable buttons, or for the sight impaired with all menus and buttons easily readable by screen reading plugins.
Local
There is not a local API but it has been much requested. A local API would allow many innovations like control panels and local interfaces. I think allowing SmartApps to expose local rest interfaces could meet the needs of most developers. According to the September 2015 release FAQ, some sort of local interaction is under consideration. I would also like to see access to more of the “Core” API here as well.
Documentation
The documentation has improved over the last year, but there are areas that if improved would lead to greater developer happiness.
SmartApp Guidelines and Approval Process
There is a single page devoted to what is very complicated topic.
Does this SmartApp duplicate an existing SmartApp? If so, does it improve the current SmartApp?
This is something I would like to hear about from other developers. Is SmartThings going to move in the direction of one SmartApp for any given scenario? How much variance is needed to justify a new submission? Personally, I think it would be better if SmartApps were reviewed only on a functional level. By declaring that there is only one official way to solve a given problem, you are stifling innovation and excluding developers from the marketplace.
Improvements could be made here by laying out very specific guidelines for submission and making a few changes.
- List specific areas that should not be duplicated
- Develop detailed style guidelines to help developers adopt a common design language
- Elaborate in communication with developers about why the submission was rejected
- Be transparent in the review process
Examples
Walk through building solutions with a screen cast. Allow comments.
Marketplace
Much has been discussed over many threads about what is down the road for the marketplace. Here are some requests and suggestions.
- Search and Discovery
- Ratings
- Versioning
- Web Interface with ability to browse and install.
- Comments
- API for the Marketplace
Selling Apps
Creating a path that will allow developers to sell their wares in an open market is becoming an absolute need for SmartThings. Open marketplaces have proven time and time again that they are the best generators of innovation. Is SmartThings as a platform going to remain a silo where new apps and devices are required to be completely individual and approved, or will it be a garden where there are many different flavors of the same idea? I understand the need for quality control, but I think a balance needs to be struck between code review and allowing the market to decide which offerings it wants.
Developer Education
The bi-weekly developer chats need more development and less tech support. Take @pstuart’s example with Live Code Fridays. How do you generate interest in new developers? Put the tools in their hands and show them what they can do. Use the dev chats to talk to developers about the real solutions they are building. Show off a new creation on every call.
Video the workshops and presentations for the developers in the flyover states. Many developers are missing out these events.
Communication
Give developers more notice about breaking changes. Use versions on the platform API. Give definitive life cycles to the versions within reason. Much was known about developer impact leading up to the release of Hub V2 and the new app and very little was shared. There should have been developer created solutions ready to go with the launch of version 2.0 of the app. Had there been an developer’s insider program, we would have had SmartApps that take full advantage of all new features on launch day.
This is meant to be a conversation starter.