Slashdot Mirror
Open Source Increasingly Replaced By Open APIs
SharkLaser writes "Open APIs might be the way to get rich in 2012. At the same time, it can also be what ultimately hinders open source development. A wide range of companies, including Google, Facebook, Amazon and Twitter, are building open APIs for other developers to use and build upon. Open APIs can be used by companies to grow their user base and introduce new, interesting features on top of their platform. Independent developers can utilize established services and their users to grow their own business. A perfect example of open APIs is Facebook Apps, which lets individuals and companies develop applications and games on top of the Facebook platform. Developers gain access to Facebook's established user base and Facebook gains new features and fun stuff to do on their site. Instead of open sourcing their platforms, companies like Google and Facebook are providing Open APIs and data access to outside developers. The actual source code for the services sits safely inside the company's network and never needs to be disclosed to outside parties, thus hindering open source development."
I would far rather have a published API than the source, especially for something like a social networking site where having the source would do me no good whatsoever. And I doubt I'm alone.
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
Isn't "Open API" just a different way of saying, "The first one is always free?"
Support the EFF and Creative Commons. The war is coming, and they're supporting you...
Like I want to build my software around an API that could disappear in 6 months to a year. Google is quite bad, imo, at dropping things out of the blue, facebook likes to break things and to be honest I'm not sure I'd want to trust their competitors either.
Most of these APIs provide access to data "owned" by the providers of those APIs. They rarely ever provide functionality that is not coupled to their data. These Web APIs are not going to replace open source tools/libraries that provide functionality.
Also, using the term Open API is bullshit. First of all, an API is pretty much always open otherwise it cannot be an "application programming interface". If the API was closed it would not even be an interface to program against but a blackbox.
For example, just this morning I replaced Debian on my computer with the Twitter API. It works great, boot times are much faster. Now I'm going to uninstall Firefox and just access the web via the Facebook API.
Remember the good old days of the Internet, in which techies used to invent useful protocols, document them as RFCs, and then the best of these would be turned into Internet standards at the IETF? That approach gave us an open Internet with multiple implementations of the same standard services, all competing on merit not through proprietary lock-in.
Well that's not where we are today. Instead we have a ton of proprietary services that occasionally publish public APIs when it suits them, but they're almost always pathologically opposed to interoperating with anyone else that might provide competition. Imagine a world in which everyone used their own homegrown mail prototols instead of SMTP and POP or IMAP. That's where we are today with the social networking services.
Walled gardens are bad. Publishing open APIs doesn't make them any better, as the gardens are still walled and these closed services reject federating with other similar ones. And even if they accepted federation, the complexity of a fully interconnected graph in which each node has a different public API grows explosively, so technically this is a very bad design approach.
Things aren't at all healthy on this front of the Internet, and proprietary services having open APIs doesn't help much. The best that can be said is that it's a bit better than no API at all, but that's not saying much.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
I'm not sure what the point of the submitter is. Open source and open API have little in common. It's not like one could develop an OS kernel based on some documented open API. Open API is also nothing novel.
Getting rich as an individual is not the point of Open-Source. Getting richer as a software-building community in terms of software availability is.
There is a lot of point. Few online services can handle the level of activity Facebook handles every minute. It's not just about tossing more hardware at it either; it's not easy to make such a scalable system.
Open sourcing Facebook gives developers access to the custom code that allows them to handle all this, making it easier for small startups to jump into large service hosting solutions.
Also, not sure what the summary means with the last statement. It is my understanding that Facebook HAS open sourced their server code (very likely as a jab at Google who, despite being "Open" would never dare give any competitor access to their scaling server code.)
Actually.... the summary does mention that the lack of open source code from Facebook and Google is "hindering open source development."
He may be question the usefulness of Facebook being open source and why would it "hinder" anything.
Still a flawed observation that I replied in another post, but at least it seems he did read enough of the summary (i.e. all of it, not just the title) to jump to his argument.
Different tools for different goals.
When you need to recreate the functionality of an existing application in a new application, as would be the case if you wanted to create a Facebook competitor, you may want the source code of the existing application.
When you want to integrate your new application with one that already exists, as would be the case if you are creating a complementary or dependent project, you want SDKs/APIs.
Developers do frequently use the APIs published for toolkits (jQuery, for example) and often load those toolkits from a third-party hosting service (like Google's, for example). This does create a dependency that would need to be updated if the hosting service made an incompatible change or discontinued their service, and that is something that developers need to keep in mind.
When developers tie into the APIs of platforms like Facebook and Twitter, it would usually do them no good to have access to the source code, as they are usually trying to tie into those existing platforms to connect with their user bases. If the developer chooses to make their application dependent upon a third-party API, that is a strategic decision and the committment is theirs to make. It makes sense if the purpose of the application is dependent upon the third-party platform.
As for published APIs interfering with open source development, I think it is possible that developers may choose to use proprietary products with published APIs rather than implement an open source solution. An example might be a developer choosing to use Google Charts rather than integrating gnuplot into their project. This might have some impact on the momentum of some open source projects, but the examples given in the summary are way off. A developer choosing to use an API published by Facebook for Facebook integration is not taking anything away from open source software.
"Published APIs" would probably be a better description for what I think they're trying to say.
It’s sad that anyone who makes a web service thinks they don’t have to, and as soon as they get 10 more users than they tested their service with the entire thing falls apart and they can’t scale it up to manage users. All they can think of is to try to optimize code here and there, but that has its limits and eventually you will need a system that can handle the scaling demand.
“Scalability” is not about being able to “be as big as facebook”, it’s about being able to handle increased user demands, be it seasonal or popularity based.