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."
What's the point of opensourcing Facebook? It's the userbase that matters to web-developers, not the server code.
Apple has "Mac vs PC", Microsoft has "Laptop Hunters", Linux has recession
Google any decent-sized software product with the words "SDK" or "API" and I guarantee you'll get at least some results.
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.
"hindering open source development"?
Yeah, sure. Just like the fact that I, like most people, don't donate 10% of my income to the FSF or some other open-source project hinders it. So what?
If you want to judge others from a particular ideological position (concealing code is unethical), you should state that clearly rather than impugn others indirectly.
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.
These APIs have been around at least since the Droid hit the market (which I was developing on). Facebook's Graph API is a newer iteration of their old API, but is at least a year old now.
I don't see how this is news, or how these APIs wiill suddenly make companies rich in 2012... when the APIs have been around since at least 2007.
while(1) attack(People.Sandy);
This is hardly new - I think you will find it dates back to at least before the 1980's. The "Open API" model was used by both the Apple ][ and the original IBM PC - and it made them very successful. I am pretty sure it was not new at the time, but others may be able to confirm that.
Sent from my ASR33 using ASCII
look at android, once the latest OS code has been released there are 20 phones coming out with it in a few months and they are all pretty much the same. you either price low or cut your margins and play the specs game. After a while, the big kid on the block aka Samsung beats out all the competition.
if you want the premium android market you pay Google a pile of cash to get into their circle of trust program
1. Make Open API that replaces ad-based website functionality.
2. Don't require ads or developer fees
3. ???
4. Profit?
I would have written more, but I think that sums up my point.
while(1) attack(People.Sandy);
Many companies have built their products on top of someone else's APIs, to have those APIs change, vanish, or develop charges later on. Do be aware of the pitfalls before you make yourself totally dependent on someone who does not have your best interests at heart.
My Journal
this is either intentionally spinned or misguided
OpenAPIs is an SDK.. how is that free and why are we supposed to believe that replaces free ?
Open Source replaced by Open APIs?
How should that work?
Two totally different things.
"we are all atheists about most of the gods that societies have ever believed in. Some of us just go one god further."
I do think Facebook is a bad example. Their API is open and the SDK is open too... yes, the code is executed remotely... but that is the whole point because it interacts with the user data... that is the beauty behind technologies like XML-RPC or soap... good luck to facebook opening up access to their whole database... they don't care about privacy but even they would not do that
now, it is true that a lot of companies provide an open SDK with a binary part... a good example would be video drivers which are open source yet include a binary part that is not open source. Games are another example.
Even then, I would still consider it progress because before that there was no SDK, the only way to modify existing products was through a hex editor... at least now, software editors provide an api to interact.
The concept is not even new... windows operating system is based on binary DLLs that many times only microsoft has the source code... yet visual studio comes with sourcecode and a very complete toolkit... but even that was not the first time open api was provided to a binary core... I guess that is just the way software is done
Never antropomorphize computers, they do not like that
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.
It's an API. Tacking "Open" onto doesn't change the fact that it's just an interface to a black box.
As Stallman's been saying for the last few years, having software freedom is about having control over your computing, and that requires that your computing is done on *your* computer:
http://www.gnu.org/philosophy/who-does-that-server-really-serve.html
Expert in software patents or patent law? Contribute to the ESP wiki!
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
If only someone could have foreseen this and warned you!
See that "Preview" button?
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.
I'd like to see the evidence that points to an inverse relationship between open source and open APIs. This article mentions it in the title but there's nothing in the (marketing) article confirming this.
Easy choice for companies. They can ride on the "openess" trend without actually giving away their business secrets.
Then the killer feature of the Open API is that it actually generates more revenue. You can sell your expertise in securing the API, documenting the interface and have your consultants provide support - and there is nobody to compete with you, because the product is new to market.
It just makes sense.
If the GPL source/binary stays within the company fences that's a somewhat clear picture.
But what if you lease a cellphone that contains the binaries? It is the company property so no distribution has occured.
What if you lease a cd-rom with binaries?
Or lease a virtual cd-rom online with binaries?
Using an API with an established service and creating your own solution with open source are two very different things that are not necessarily mutually exclusive. Rather than open API vs Open Source, I think it would more be about using someone else's system vs creating your own. There will always be situations why picking one over the other will be advantageous. However, this has more to do with the goals of the project than one method being superior to the other.
Sdelat' Ameriku velikoy Snova!
Emphasis Mine.
There's a lot of places to come down on this. I develop with Google Apps, which leverages a lot of Open Source software in order to grant me the functionality to develop applications. I don't think that Private APIs are necessarily a hindrance to Open Source; They can obviously (and currently do) serve as a complement to provide necessarily complex and costly access to functionality my application or the machines that it runs on can't provide. And for me, the complex and costly bar is low, and this is where the line "Open APIs ... require less geeky access to lines of code, and more programmatic interaction with software services" actually shines. I hate running my own RDBMS on my own private web host. I don't really feel like setting up cron and the permissions on an account so cron can run a web application task safely. They are complications I don't care to deal with. Same with designing simple user account systems and storing passwords. These are problems I want solved, and most open source frameworks don't care to solve these problems for me. Google Apps does. And that's a huge complexity and cost (in terms of time) I'd have to invest micromanaging those things when I want to just write an application instead of doing server maintenance. And I know I'm not alone, or else there wouldn't be successful applications deployed on Google Apps.
But that doesn't mean I don't use webob, or the open source WebApp2, or any of an additional set of open source python modules for various functionality in my application, and I am extremely grateful to those Open Source developers that chose to permissively license their modules. Without them, Google wouldn't be able to offer their services, and I wouldn't be able to leverage them.
This Idea is not new I mean MSFT has been doing this for a long time. IMO is this the best way for companys to release their products because A. it protects their works, but B is allows other people to make their products great. The problem that we see like mentioned was companies like Google who remove services but yet on the other spectrums we still have MS DOS support in Windows 7. I think companies can open up their APIs which allows protected business interest but still allows improvement for the development community. The idea why keep reinventing the wheel?
Companies offering Open APIs are not hindering open-source developers.... Open APIs remove barriers for all software developers and allows them to make interesting products. What hinders open-source developers is other developers keeping their source code closed.
"Open" API's are the new include files to proprietary libraries.
At least in the good old bad days the library (usually) didn't stop working after the you compiled & distributed your program.
These days.. no such guarantees.
Open Source is not replaced.. look at the list of companies involved. Google and Facebook built their entire system on open source software. Linux, MySQL, PHP, etc. Facebook and Google have track records of contributing software back to the community as well.
Nothing stops me from writing a plugin for Joomla, Drupal, Wordpress or some other open source package that integrates with a Google or Facebook API. I don't see how one kills the other.
I can't see any indication of more API being used or provided instead of open source. Even the companies listed always kept their data and most important software inside the company. There was no open source version of amazon's store or cloud computing software, none of google's search engine, ... and so on. They almost only published their deprecated or value-adding tools for the customer as open source, or things they were obliged to publish due to copyleft licensing. They also long had an API or data interchange formats for the services they offered.
Thus, I think TFA really is preposterous in how it somehow constructs open source to have been filling the role of API in the past, and the "new" cool world of big standardized API as the solution to much needed simplification in an ecosystem allegedly too diverse and complex. It is just the needs of businesses and people that are complex, and while some redundancy could be cut, for the most part that's how it is.
In short, I cannot see anything about API replacing "open source" being indicated in TFA. Even the few companies named in TFA and summary are not doing anything significantly different from what they always did. There really is nothing to this article.
For the *most* part, the technical capabilities of sites like Facebook isn't the impressive thing. At small scale, anyone can make code to function well in that capacity. If your endeavor grew to the point that facebook does, you'd have the resources to do the harder, but not impossible part of making that stuff scale. These sites are not succeeding because of inherently superior technology, they are succeeding by knowing exactly how to draw everyday users into a platform. What philosophy to embrace (e.g. enforced consistency upon the users compared to myspace I think plays no small part in their success).
Google has some interesting backend mechanics, but mostly in their case the bigger factor is the data they have accumulated and resources to acquire and store new data, with or without registered users. If you had software that could match Google Maps perfectly, it wouldn't matter if you don't have the maps, satellite, aerial photography, the street view, the ever-changing list of addresses and some meaning behind them (e.g. search for 'burgers' should include "McDonald's"). Some of this is big compute resources to crawl everything and drive cars around cities with cameras, in other cases they have business relationships to acquire data where millions of dollars changes hands.
As code-centric people, we fixate on the code that glues this together, but in the most 'dangerous' cases against a 'Free' world the code being released does nothing as the userbase and/or proprietary data that powers it matters and massive compute resources are required to actually deal with it even if you had magic free access. No matter how you slice it, it is a capital-intensive game to play. The best a distributed endeavor can realistically hope to do is to piggyback on one of the large companies infrastructure using published APIs.
XML is like violence. If it doesn't solve the problem, use more.
If you can't change API, it aint "open". It's just published.
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
Open APIs are about directing more users to their webs. Open source is about bringing developers together. Says, how can an open api replace an open source os?
An API is just an interface - there's nothing inherently open or closed about it. The code behind the API might be either open source or closed source, and in this case we appear to be talking about closed source.
Not only is open vs closed a meaningless adverb to apply to an API (the closest concept might be public vs private - e.g. hidden Winodows API's), but the trend the article is attempting to discuss is the growth of cloud based platforms - i.e services made available via web services (SOAP, .NET, etc).. it's got nothing to do with open or closed source.
Maybe the ultimate example of a "platformization" is Amazon - whose entire company is based on their own publicaly available (at a cost) web services, and this is where they make a lot of their money - from other companies building their web-based stores and services on top of the amazon platforms/services.
Assuming there *was* one universally accepted standard that Facebook embraced and was also implemented by MySpace. No one would still give a rat's ass about MySpace. The APIs in this case are trivial and you can make up your own or copy them as a de-facto standard, but the data and user connectedness that the service embodies is what matters.
There are two good reasons these companies don't go through RFC process for things like this. One, as above, the APIs are trivial and only of value to their data so an RFC process makes no sense. Secondly, if they were married to the RFC process, every little enhancement has the potential of taking months to over a year to ratify. Nothing is stopping a community for creating an RFC to compete with a proprietary API and if you push it through and are successful and create an ecosystem, then Facebook might implement it on top of their proprietary API.
Incidentally, the same phenomenon can be seen in the 'good old days' of the internet. Cisco frequently did (and still does) roll out a proprietary protocol and when the IETF finally ratifies a standard to do the same thing, Cisco implements the standard as well as their proprietary approach (ususally, some times Cisco ignores the standard, probably due to lack of explicit customer request). Also, at the upper layers, there is a large precedent for people not bothering with RFCs at all. As far as I know, there is still no IETF RFC covering bittorent. There we have a very popular, community driven technology that has been in use for years that doesn't bother with IETF RFC process.
XML is like violence. If it doesn't solve the problem, use more.
A company exposing an open web services API could endorse an open-source reference implementation of a client program that interacts with the API in a best-practice manner. I wonder if someone might have been complaining about lack of such a reference implementation.
"Published APIs" doesn't help if one of the parameters is a cryptographic key to identify an application and keys for interacting with the production environment (as opposed to the sandbox environment) are hard for developers to come by.
So what do you do once your application gets so many users that your application key to access the "Open APIs" starts hitting its quota of queries for the month?
There's two kinds of open APIs in the world. Those that promise backwards compatibility and those that don't.
Those that don't are free to improve their product release over release in any way they see fit. Previously existing plugins may however break as a consequence of an open API change, creating problems with users who expect their plugins to continue working and plugin developers who hear from their users or lose reputation when their plugin blows up. Plugin writers are expected to rewrite their plugins with every new release. They hate this, and what's more some plugin writers will not, forcing the user to chose between your upgrade and their plugin.
Let the finger pointing begin.
Now, those that do promise backwards compatibility, they're TOTALLY screwed.
The number of ways exposing your API and keeping it backwards compatible has of eroding and eventually destroying your code base is an awesome thing indeed.
You cannot remove anything you've ever made public. If you do, you break everyone.
If those un-removable things represent constructs which are central to the intellectual framework of your public API - what makes your API comprehensible, guessable, sensible, and you've made a mistake in your conceptualization or more likely you've made a decision which reflected an immature or incomplete understanding of your domain, the only way out of your bad decision is to create a new API with the new concepts that is sort of like the old but not really because here's the way we're thinking about our domain now... hello? ... hello? ....are you with me?... hey... where ya goin?...
Only in very static domains in which there are very strong public conventions about what does and does not exist is it possible to know with anything approaching certainty what set of concepts will prove durable and which are dead ends and over simplifications / over complications.
You have no idea what class names developers are using in their own libraries. If come to use the same class name as they are using, then unqualified uses of the class name in any file which imports both libraries is rendered ambiguous. Now your next release is breaking any plugins who used any of the same names in their own private libraries, even though those plugin developers did exactly what you wanted and nothing which was forbidden. Whose fault is that? heh heh heh.
Backward compatibility also has the effect of forcing you to freeze key parts of your internal design which have accidentally leaked out into your open API owing to leaky abstractions. And there will be lots of them. Yes. There will.
People will use your API in unexpected ways and come to rely on the the peculiarities of the particular implementation you thought you were hiding behind your open API. We're talking developers using things like program flow and call order of your private methods, relying the fact that you're running something on a particular thread, timing issues, the fact that a method doesn't return NULL etc etc. None of these things is documented as part of your open API, yet developers will come to rely on them and be angry and confused when it doesn't work anymore.
If you expose in anyway a String type, then rest assured plugin writers WILL find it and come to depend on it. Which brings us to the issue of plugin writers using whatever reflection capabilities your language offers.
Sure some of this is their fault (and a lot of it is not) but so what? What do you think when as a consumer your software blows up and you write the person you bought it from and they point the finger elsewhere?
Whole parts of your language toolbox are just off limits. You cannot expose non-final anything because someone will extend it with a method or field name that you yourself will want to use later, causing the above mentioned name clashes.
. . That means you cannot improve your OpenAPI through the techniques of extension and inheritance.
If we really want a free software web, ðe only way forward would be ðe wide adoption of servers under ðe Affero GPL v3.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
I thought the exact same thing. How do open APIs on facebook replace Linux as an OS?
The open API model was used at least since the late 1950s, business computer systems have always needed customization and developers.
"a Windows developer has absolutely no use for the Windows source code"
Stupid devs don't look under the hood. They don't even know what is running on their system most of the time. That is exactly why there are so many virus issues and zero-day flaws that remain unpatched. Have you heared of UPnP, DCOM, SMB, NetBIOS or any of the other easily exploitable Windows "services"? How about the trojans inserted into VNC for Android Phones?
You can live with blinders on, or you can view the source.
I retract my criticism, I somehow completely missed the point about federation and assumed someone was oversimplifying the situation (as the original article did). Of course, open source is orthogonal to this (this thread hasn't brought it up, so I think that's well understood), you have to modify the behavior of Facebook, not have read access to their source.
XML is like violence. If it doesn't solve the problem, use more.
Only if certain vested interesteds would like it so. If such it would be a disaster for the ecosysten .. er ... monoculture. It will be good for the people who develop these "open APIs", but not so good for the rest of us.
Consider this - Facebook uses a lot of open source projects to deliver their site; and they've contributed a lot back to those projects. They may not release source directly (though there is http://developers.facebook.com/opensource/), but does that really matter in the end (as others have pointed out)? Even if they don't contribute 100% of their changes back (which since they are not distributing the code to others they are perfectly fine to do per the GPL - all versions of it), they are still doing well with promoting open source in many ways, and the fact that they've opened up an API that others can utilize without hinderance enables the platform they do deliver to be relatively easy to access from RMS "free" open source areas.
Same for Google, which does do some distribution but also funds a lot of open source projects through Google Summer of Code.
So how exactly are they hindering open source?
Even Microsoft has released several projects (wix.sf.net to name one) under true open source terms (GPL).
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Google once offered access to their search engine via a SOAP API. That disappeared years ago. Then they offered more limited access with the "Google Web Search API", which came with an obfusicated interface, a restrictive EULA which permitted its use only for widgets on a web page, and is now closed to new users. Now they have the Custom Search API, where you get only 100 queries a day before you have to pay.
Yahoo used to have a Yahoo Search API, which was free. Then they had the Yahoo BOSS API, which was also free. Now they only have a pay API.
Bing's search API remains free, but you have to sign up with Bing first, and Microsoft reserves the right to start charging.
OpenAPIs are when you dont want to manage the hardware. That's all. It doesn't have anything to do with Open Source.
Open APIs can be used by companies to grow their user base...
Seriously. Stop that shit. "Grow" is not synonymous with "increase", and no, you don't sound cool.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
As a software developer this is a serious question for me and one that I've never gotten a satisfactory answer to.
How can I feed my family or control my own destiny if the software is all I have? Am I not dependent on the benevolence of a corporation or university to fund my project or work as a clerk or something during the day and code at night? I know Open Source companies can make money on services or hardware but I'm not an Open Source company, I'm just one guy trying to make a living. I don't have the capital to produce hardware and my software is designed for end-users who don't require much in the way of services.
If I were working on some glue code that might be useful to other developers and where I would benefit from their contributions I certainly would open source it (and I do contribute patches to some of the open source projects I use). I also get the idea of an open source OS or other large projects because so many companies depend on it there are enough "payers" in the pool to fund a lot of full-time devs - more than enough to cover the people who make millions off it (eg: Linux) yet contribute nothing back... plus with millions of users you have enough part-time tinkerers that you also get significant contributions from them.
But I just don't see why I would open source my apps. No company in the world can pay my salary based on them, yet there are thousands of users willing to pay $0.99 for them, enough that I can keep my hardware up to date and have a little bit left over to go out to eat every month (certainly not enough to quit my job). But there aren't enough users that there would be a lot of programmers willing to contribute.
If I open-sourced them, I'd be in the same position as Google with Android - funding the majority of it but having Chinese search companies replacing all my services with their own and selling it while simultaneously cutting off part of the revenue stream I use to fund further development.
I like open source, I use it, I contribute to it, but I have absolutely no desire to follow the Stallman "everything must be open source!" philosophy. I'm interested to hear other dev's thoughts on this stuff...
Natural != (nontoxic || beneficial)
should read: "Universal Literature Increasingly Replaced By "The Walking Dead" episodes". FTFY.
Most of the platforms with APis are running on open source and their developers are contributing code back. Nothing to see here.
-- $G
If the API for something is open and well document, that's already one major step toward implementation. I think open API's are a good thing, because when that kind of information is out in the open, proprietary services may exist, but also open source developers are more free to implement their replacements for those services or systems. This is much better than, say, having to deal with software systems that have secret and closed API's, to the extent that you can't make anything that's even compatible with it.
Just because you can hook into a service doesn't mean it will be available later, or available under the same terms and conditions. Better to be able to control your own destiny.
Twinstiq, game news
#3 Capture all the private data being sent via the so called "Open API"
facebook -> diaspora (diasp.org) other pods are available @ http://podupti.me/
twitter -> http://identi.ca/
google -> make your own using wget. or use crawl data from http://www.commoncrawl.org/
Developing software that uses APIs is nothing new. There's really nothing special to make these "Open" APIs.. I'm sure there's a few pieces of software where the software owner considers the API to be some big trade secret but generally API infromation is publicized. Programming for a publicized API implemented using proprietary code is nothing new... Windows, OSX (fanbois will bring up the BSD basis, but that does not cover most of the OSX API), and so on. This is completely orthogonal to rather the actual app is open source or not. I have not seen any evidence that programs running on so-called open APIs (Facebook, Google maps, etc.) are displacing open source apps. They server different purposes.
Open Source is also replaced by OpenOffice, Shared Source etc. Stop basing your decisions on matches in product names. People won't stop eating apples, if you give them ipads to eat.
You can call Google and Facebook things APIs. I call them data miners and proprietary libraries designed for specific application. 'Free online stuff' users fail to realize that they are running third party code on their sites and that code is outside of their controls.
Could facebook be termed a generic made into a monopoly or a just monopoly.
Was it not that logic that forced Dupont to sell its nylon 66 process in the 1950s.
Could it be the justice department should intervene and break it facebook?
It would be interesting to hear some legal discussion on this point
In my view APIs are just short term to proving ground for new concepts that deliver long term value chains in the consumer and corporate market. By its very nature open APIs that are controlled by a third party can never reach maturity due to conflict of interests.
The challenge for open source software developers is to provide the same or better solutions and functionality in ways that gives the end user (consumer or business) full control of their destiny. This includes control of costs, data, usability, scalability, functional extensibility etc.
I have an incentive to free my code: Reputation.
I don't do consulting anymore. When I did, many clients arrived to me as I was a well-known figure in my country's free software circle – Mostly as a speaker and as a security-conscious sysadmin, somewhat (although by far not so much) as a programmer. I was able to set the costs for my work because people arriving to me didn't just want a random firewall salesperson – They wanted me to set up their perimetral security.
Nowadays, I don't do consulting because I have a job at the university that allows me to be freer, schedule things my way, do what interests me. How did I get this job? Same thing: I showed I knew my lines way beyond what a resume can do it. I showed the projects I worked with.
Were it not for free software, I could not have had access to the tools I used and learnt with. And I could not contribute to projects. And I'd have a shittier job.
a few people on this planet still write and run programs to do things other than social networking, and some of them release these programs as open source.