Posted on 02-03-2013
I did a presentation at the DC API Meetup, when I was in Washington DC last week. My talk was some of my usual material around the history, business and politics of APIs, but included a section on trends, where I covered some of the newer aggregation providers like Singly, BaaS providers like Parse and automation tools like IFTTT.
At the end of the meetup, we did a QA panel session, and Javaun Moradi (@javaun), product manager at NPR digital, made a great point about the reliability and stability of this new generation of third party platforms building aggregate, backend, automation or other types of providers who are in turn, dependent on other API providers.
Javaun questioned the reliability of this new generation of startups, who are newly funded, most likely not yet profitable, dependent on other APIs, and are most likely going to be acquired later on down the road, or go out of business when funding runs out. Javaun felt that established players like Salesforce and Google are here to stay, you know they aren’t going anywhere--where a new startup has greater potential for service disruption and instability.
If you are building your app, and depending on an aggregate API service like Singly, or backend as a service (BaaS) platform like Cloudmine or reliant on a automation platform like Zapier, you want to know the company is going to be around in a year. Right?
In my opinion, the number one way these new breed of startups can alleviate these concerns, is by solving developer problems, delivering value (which every company I’ve mentioned is doing) and have a clear business model. Success is the best solution, right?
Another way these startups can instill confidence in the developers who are building apps around around their services is to also offer open source options. By offering API aggregation, backend and automation as a cloud service, while also as open source download and fork, this new breed of providers can do a lot to build confidence and goodwill with potential users.
Some good examples of this are:
- Singly - Singly AppFabric empowers you to add social login, sharing and friend finding into your mobile and web applications, and Singly Hallway is the open source version to help developers build amazing applications combining data from many sources easily, through one API.
- OpenKit - Open source, cross-platform backend services for game developers. It will be available as client and server download on Github, and no mention if it will be a cloud service
- Rules.io - Rules.io is a rules and segmentation engine with companion Geekier which is part of the rules.io service as an open source framework
These are just just a couple examples of how startups are emerging to provide a new approach to rapidly and efficiently building web and mobile apps across many APIs. These platforms are all about delivering the resources developers need to efficiently build and manage web and mobile apps, without the overhead of rolling out the infrastructure on their own. With an open option, if for any reason the startup should change or go away, app developers have the option to put the open codebase to use.
This approach will not be for all startups, but with the neck breaking pace in which startups are born, evolve and die, and open by default approached bundled with a healthy as a service option, looks like a positive approach for platform providers, developers, end users and the overall business sector.
As more providers emerge in this space, I hope they choose to adopt an open by default approach.
comments powered by Disqus
Winning in the API Economy
|Download as PDF|
Latest Blog Posts
- Top 5 Most Popular Themes On API Evangelist In 2014
- Query Parameter Determining Which Fields Are Queried For API Call
- Now Our Development Environment Is Now Containerized And Scalable Like Our Production Environment
- Guest Post: Let Our Sponsors Blow A Little Smoke Up Your Ass
- API Discovery Continues Its Move Into The IDE With Eclipse Che
- Evolving Beyond Just Resources Towards A More Experience Based API Design
- Another View of The API vs. Data Download Model
- If You Have A Publicly Available Mobile App You Have a Public API
- Reducing The API Stack Down From 830 to 690
- Gathering My Thoughts Around Common Patterns For Base URLs Across Nearly 700 APIs