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.
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.
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? ;)
Oversimplified refresher for anyone wanting to know what we're talking about:
Least restrictive
* MIT/2,3,4-clause BSD/Apache (pretty much anything, the terms are clear (except Apache))
* LGPL (usually for libraries that can link to non GPL stuff)
* GPLv2 (if you change the source and ship product, you must reveal the source. can't link with other licenses)
* GPLv3 (closed the Tivo loophole)
* Affero GPL (no services)
Most restrictive
Without a license being specified, it's difficult/impossible to include a project in anything commercial.
GPLv2 : You may copy, distribute and modify the software but you must relicense any changes and your entire project under GPLv2 and disclose all the source code
GPLv3 : You may copy, distribute and modify the software as long as you track changes/dates of in source files and keep modifications under GPL. You can distribute your application using a GPL library commercially, but you must also provide the source code
AGPL : The AGPL license differs from the other GNU licenses in that it was built for network software. You can distribute modified versions if you keep track of the changes and the date you made them. As per usual with GNU licenses, you must license derivatives under AGPL. It provides the same restrictions and freedoms as the GPLv3 but with an additional clause which makes it so that source code must be distributed along with web publication
The most restrictive for me for commercial use is GPLv2, because you have to open source ALL the project, not only the modified part.
With GPLv3 and AGPL, just the modifications of the source code , not all the project.
It is a question of point of view about "restrictions".
Nope. AGPLv3 is very different from GPLv2. Also the wishes of the creators of Linux and git make the GPLv2 more comfortable to me. Companies that have a dual-licensing model with GPLv2 and a paid proprietary license may try to stretch the meaning of the GPLv2 to make it more restrictive.
The problem with oauth.io is I could spend time learning it to use it on a personal project and then not be able to apply the same knowldege on a client project where the client doesn't find the copyleft situation acceptable.
You like to get to use some software for free, but you also want to use it so others might not see your modifications.
How exactly is this different from GPLv2, if the web service you were writing was going to be shipped on a router? and why should you be allowed to use someone else code but then prevent others to see your modifications?
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.
Doing what SugarCRM is doing would be better than what they're doing right now. Many companies would find both AGPL and SaaS against their policies but would be OK with paying for non-copyleft software that they can install on their own server.
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.
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.