nadiac

Hopefully a backend that lets me stay in my own environment and don't oblige me to code on THEIR hosted cloud platform. I like the WYSIWYG approach, as far as I tried it seems not limited like classic wysiwyg interfaces.

You guys should open source to have the full community behind you to make the Parse that Parse should have been. Easy to use, Open, community driven and deployable anywhere.

"The design of Everyday things" Donald A. Normann

Me too, I accept only Google for my personnal identity. Sometime Linkedin or Github when that make sense and there are more features as importing your contacts/repos for more networkingcollaboration etc... Facebook and Twitter is a big NO everytime.

Now Google is not the only one place to look for public APIs.

May be they will go like MongoDB, RethinkDB, OpenERP, SugarCRM as well as WURFL, they all now utilize the AGPLv3 as a vehicle for dual commercial licensing.

may be to your mind GNU/GPL is also "technically open source, but not what most have in mind." Licenses that enforce open source to spread are to my mind more in the open source spirit than MIT or Apache2.0

You think that people understand open source as free (as free to re-use)? I don't believe so, there are many open source licences for these reasons, depending on the willingness of the authors. Linux is open source or not? ;)

I think they mean serverless here more about the user experience because the user doesn't have to install a server to make it possible.

Because there is here as you mentionned Oauth.io server, but also Github server and lots of other servers for fonts/librairies etc...

Nothing is technically "serverless" on the web ;)

Can be it used to find open source client side code/libraries that are used out of the open source licence?

This website http://habrahabr.ru/ makes you more visits than HN #1 in front page, and for me this is the russian HackerNews

Oauth has been made to avoid to store passwords, but it is not a simple protocol to implement. I just think you are talking here about the main debate between protocol versus applications/platforms.

- Protocols provide standardization, and independance, often as recipe/instructions to follow. Protocols keeps things open, into nodes not hubs.

- Applications/platforms provide easy comsumption, with a user design but also dependancies. It is like a menu to order, as you choose what you want to eat but you don't have to care about how to do it (the recipe). They mutualize things as code librairies, CPU etc... but are hubs, not node and close the network in counterparty of user experience.

To see in depth the difference of design between a recipe and and a menu, more explanations in the Donald Norman book " The Design of Everyday Things"

Edit: To see the difference between a protocol and an application, why people are using Gmail instead of STMP? User experience vs implementation

I feel it is made for fast Oauth integration. We use 4 oauth providers into one of our app, and it took us really 4 full days to implement them without bug. We are not Oauth experts but it was really boring and IMO useless implementation time.

Also I'm personaly making a client-side app on a Github page and it seems that with oauth.io I could make a serverless Facebook/Twitter authenticated app.

Toothbrush and mouthpaste for the 2nd day morning

Still depending of your users. Ir your users prefers an other language than english, do it. It can be a competititve advantage. But be sure to know your users to do that, because english is ruling the API documentation world.

Yes, because lot of people don't make the job to go out of the building and talk to their users. They make a neutral interface, for everybody. This is why sometime their API seems not consitent with the real need that they solve for your application/business.

When you design your APIs, you put a paradigm into depending who will be your user. I know for example a Hotel booking API which for the same resources expose 3 differents API depending on their final users.

They have one design for airplane tickets services (which requires sector-specific naming standards), one other for other Hotel booking sites and a last one for long tail developers. It is the same ressources but 3 differents APIs for exposing it, because they know their user needs.

I just think that when you design your API before knowing your user/customers, your users will be as you said in the article "not who you think they are"

A famous chinese proverb: "if you don't know where you are going, you will always arrive in a wrong place"

Edit : that resumes the issue I'm talking http://apijoy.tumblr.com/post/51977839347/when-you-didnt-exp...

Come see us today in SF @Parisoma 11th Street/Howard (for the APIhackday we organize) Some coffee/bers, foods, hackers and entrepreneurs there