You are reading a single comment by @Velocio and its replies.
Click here to read the full conversation.
London Fixed Gear and Single-Speed is a community of predominantly fixed gear and single-speed cyclists in and around London, UK.
This site is supported almost exclusively by donations. Please consider donating a small amount regularly.
@Velocio
I'm satisfied of the above (and I actually read the articles of memorandum end-to-end, some 110 pages!).
The API is a public interface.
In the same vein as these ones:
https://stripe.com/docs/api
http://disqus.com/api/docs/
http://www.meetup.com/meetup_api/docs/2/events/
https://developers.facebook.com/
Because of the way Microcosm aims to build revenue, which is through the content itself rather than through banner or display advertising, we want... no... NEED developers to embrace what we're proposing and to build clients based on them.
It becomes a competitive advantage over time to have a well-used API... because it allows communities to implement clients that fit their niche of niches needs. And it also allows platforms that we could not immediately service to have clients built -minority players like for the iPhone ;)
An example, the polo guys could use the API to create a tournament application in which events, discussions, etc were powered by the Microcosm API yet actual game results were powered by their app.
The API is what allows such blending, and they allow clients to be create that fulfil niche needs which in turns helps with traction and growth.
There are very good arguments to be made that some companies (Twitter, and Stripe) grew solely because of their open API and the simplicity and consistency of it. It was trivial to make an app that provided functionality in a way that suited the needs of different minorities of users.
Where Twitter went wrong is that they rely on control of the client to present sponsored (display) adverts. But as I mentioned above, this is one of our strengths and not our weakness.
The API discussion will be very open, as will the front-end. Where it is easily argued that core IP and value needs to be protected is in the database schema, the backend processing, that is the architecture of everything behind the API.
That's the stuff that will be protected, virtually everything else will be open.