Slashdot: News for Nerds


Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Open Source Increasingly Replaced By Open APIs

Soulskill posted about 2 years ago | from the playing-with-somebody-else's-toys dept.

Facebook 224

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."

cancel ×


What's the point? (3, Insightful)

eugene2k (1213062) | about 2 years ago | (#38537616)

What's the point of opensourcing Facebook? It's the userbase that matters to web-developers, not the server code.

Re:What's the point? (3, Insightful)

hjf (703092) | about 2 years ago | (#38537638)

On your race to the First Post you completely missed the point. Hell, you even missed the headline!

Re:What's the point? (5, Insightful)

Tharsman (1364603) | about 2 years ago | (#38538018)

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.

Re:What's the point? (0)

Anonymous Coward | about 2 years ago | (#38538070)

I think he got it. It seems like he just meant to ask why Facebook would bother or care to made their APIs open source. There's no benefit in it for them. It's not like they aren't control freaks.

Reference implementation (1)

tepples (727027) | about 2 years ago | (#38538628)

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.

Re:What's the point? (4, Interesting)

Tharsman (1364603) | about 2 years ago | (#38537974)

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.)

Re:What's the point? (0)

jedidiah (1196) | about 2 years ago | (#38538080)

> it's not easy to make such a scalable system.

Then don't try. Don't try to make the largest tower of babel.

It's sad that anyone thinks we need to.

Re:What's the point? (4, Insightful)

Tharsman (1364603) | about 2 years ago | (#38538282)

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.

Re:What's the point? (1)

garaged (579941) | about 2 years ago | (#38538136)

Very few services need that kind of scalability, and is not that hard to achieve it actually, just look at how many examples we have, you just need the money and motivation ( most of it is hardware, good software is way cheaper )

Re:What's the point? (1, Insightful)

Mathinker (909784) | about 2 years ago | (#38538162)

> Also, not sure what the summary means with the last statement.

Seems to me that it means "I am a card-carrying member of the Church of RMS, and I'm not about to let any real facts get in the way of disparaging those of less pure faith".

As you point out, it seems a bit stupid. Possibly useful for artificially pumping the Firehose to get a submission on the front page, though.

Re:What's the point? (2, Insightful)

camcorder (759720) | about 2 years ago | (#38538134)

Security. If Facebook source code was open, security flaws which are disclosed every one day or another, probably ruining life of thousands due to privacy leaks, would have been closed faster and I'm sure dozens of sane coders would report facebook to close its bugs. Moreover Facebook engineers would be more careful. Windows taught the lesson that security from obscurity is flawed decades ago.

Re:What's the point? (1)

Bananana (1749762) | about 2 years ago | (#38538520)

Security. If Facebook source code was open, security flaws which are disclosed every one day or another

it would not be the case if they're open from the first day on or at least open earlier.

Re:What's the point? (0)

Anonymous Coward | about 2 years ago | (#38538158)

The point is that as the "real world" moves more and more into cyberspace there's a rather convinced movement that wants that world to not contain property rights or barriers that say "what is yours is there, what is mine is here". They tried it in the real world quite a bit, and I admit that GPL v3 was a clever virus. Seems to have failed.

Software packages, too (1)

windcask (1795642) | about 2 years ago | (#38537620)

Google any decent-sized software product with the words "SDK" or "API" and I guarantee you'll get at least some results.

Re:Software packages, too (5, Informative)

nman64 (912054) | about 2 years ago | (#38538026)

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.

I see no problem here. (5, Insightful)

bigstrat2003 (1058574) | about 2 years ago | (#38537630)

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.

Re:I see no problem here. (-1)

Anonymous Coward | about 2 years ago | (#38537776)

That's because you're clueless.

Re:I see no problem here. (4, Insightful)

betterunixthanunix (980855) | about 2 years ago | (#38537812)

The problem is that web app APIs can change at a moment's notice, without any announcement, and all the developers who depended on the API will be left out in the cold. If Facebook wanted to, they could kill, hinder, or otherwise put any particular third party app at a disadvantage by simply changing the API a little. The running story with web 2.0 is that everyone is at the mercy of the people who run websites; this should not be news (in fact, the problem was discussed years ago).

Re:I see no problem here. (4, Interesting)

Tim C (15259) | about 2 years ago | (#38537992)

The problem is that web app APIs can change at a moment's notice, without any announcement, and all the developers who depended on the API will be left out in the cold.

While that's true, if they do it too often and to too great an extent they'll lose developers to some other platform; if the apps start breaking without replacement, users will start to leave for other sites. Facebook (as big as it is) is nothing without its userbase.

Re:I see no problem here. (2)

HarrySquatter (1698416) | about 2 years ago | (#38538054)

Except doing such a thing would drive away the very developers they are trying to bring in thus would kill their site.

Re:I see no problem here. (1)

Anonymous Coward | about 2 years ago | (#38538262)

But isn't your argument orthogonal to this discussion? Absolutely they can change the API without notice. They can change the production source without notice too. Either one breaks apps that layer onto the service. It doesn't matter whether you have the source or not, your app / game / service stops working when a change is made. They publish a new API and you fix your code to use it. Or, they publish the source and your struggle through that and figure out how to change your code to make it work again. Generally it is faster to read the new API and fix your project that way (as long as the API comes out when the change does - or even before the change).

Re:I see no problem here. (5, Insightful)

ortholattice (175065) | about 2 years ago | (#38537956)

Yes, and a Windows developer has absolutely no use for the Windows source code as long as they have access to the APIs. So why would anyone care about Linux?

While you in particular may not necessarily have a use for the source code, the point is that it is unavailable to those who do wish to use it. The "use" might be understanding what it is doing (what information is it sending to the parent company), modifying it (so that it does not do this), and having the ability in principal to continue to run the API (modified to run on your own or an alternate social network) if the site owner goes out of business, does things you don't like with the information you give them, or decides to ban your application.

Re:I see no problem here. (5, Insightful)

jedidiah (1196) | about 2 years ago | (#38538122)

> So why would anyone care about Linux?

People care about Unix and Linux is just another Unix.

THAT is what freely re-implementable interfaces get you. Now while it is possible to have proprietary interfaces that can be re-implemented, it is very rare. The whole point of "owning" the API is the fact that you can disallow drop in replacements. You are you're own monopoly and market pressures quickly enforce that.

We haven't moved from Free to Proprietary but from proprietary apps to proprietary services where all of your eggs are in one basket at some Facebook owned data center.

What's missing is mobility of data between different "compatible" services.

Re:I see no problem here. (1)

TheCarp (96830) | about 2 years ago | (#38538004)

Embrace the power of AND.

I want....both! (I also want it immediately for no cost, but thats just typical isn't it?)

Seriously though, the source availability may not be of use to you now, directly but, if you don't think it is of use to you, then realize that if the service with the published API goes away, you don't have a starting point to replace it, other than the API docs... unless someone else already implemented another version off the same docs.

There are definite plusses to independent code bases... but they have to exist in parallel to be useful. If nobody starts work on a new code base until the original service is gone, where does that leave you?

Re:I see no problem here. (0)

Anonymous Coward | about 2 years ago | (#38538310)

And how many times in your long programming career have you delved into the bowels of the Linux source to build a better *nix application? How many times have you looked into the source for the network or disk IO libraries to make your applications better? Sure it happens on rare occasions, but it's not something the vast majority of developers ever do outside of just wanting to because they can. Thus not having access to the source code isn't a big deal for 99+% of the development done out there. The *only* exception I would give to that is when the APIs are poorly documented.

And you also miss the main reason for APIs in the first place when you say "you don't have a starting point to replace it". That's the beauty of APIs, all you have to do is start using a new API. The majority of your core logic remains untouched especially if you've used proper modeling techniques and wrapped the API calls in their own library/object so it is simpler to update/replace.

Re:I see no problem here. (1)

TheCarp (96830) | about 2 years ago | (#38538486)

Yes but, you are thinking in terms of a developer. its true, API docs are a great starting point, and if well done, will allow you to recreate the whole API from scratch.

Now.... its friday at 6 pm. Your companies bread and butter is an app that was built on top of an API run by a company that just shuttered its doors forever.

If that API was based on open source, then you may have a few hours, or a day or so getting dependencies, looking over docs, getting it installed. Hell, if its really complicated, maybe a couple of days.

To do the same from scratch? You going to have that site back up by monday?

Re:I see no problem here. (0)

Anonymous Coward | about 2 years ago | (#38538770)

Even if you had the source code for Facebook or Google do you expect to rebuild it overnight if they magically went away overnight (hint, companies that big don't just disappear overnight)? There is more to FB and Google than just their code and just because you have the code doesn't mean you know how to run it all together. Even assuming that you have all their code and it's just as simple as PHP running under Apache and you can get that all running by Monday, you still have no users, their content, or any way for them to find your new platform (or do you think you can also magically take over the FB domain name in a weekend?).

What you are proposing is inane and shows you have no experience working with (much less managing) large scale systems. I've done large scale system support (average of ~5k hosts per Sys Admin, peak was ~20k before I left that company) and I've talked to Ops people in Google and Amazon and the scale they deal with makes me feel inexperienced.

Open API? (4, Insightful)

dyingtolive (1393037) | about 2 years ago | (#38537634)

Isn't "Open API" just a different way of saying, "The first one is always free?"

Re:Open API? (5, Interesting)

ThinkingGuy (551764) | about 2 years ago | (#38537724)

Another way of phrasing it (which I remember being used in the context of Microsoft's API): "software sharecropping."

Re:Open API? (5, Insightful)

Tsingi (870990) | about 2 years ago | (#38537914)

Another way of phrasing it (which I remember being used in the context of Microsoft's API): "software sharecropping."

I don't know why this is marked flamebait. I think the comment is rather astute.

What is the point in building code to support a library that puts you in a position wherein you immediately become dependant on something you cannot control. Resulting in a product that largely makes money for someone else.

That's not flamebait, it's wisdom.

Re:Open API? (1)

gl4ss (559668) | about 2 years ago | (#38538340)

you know what's the only api product I used that did that?.. google api(for the search, back in the day). 1000 queries free per day.

Re:Open API? (1)

brainzach (2032950) | about 2 years ago | (#38538418)

What is the point in building code to support a library that puts you in a position wherein you immediately become dependant on something you cannot control. Resulting in a product that largely makes money for someone else.

Many developers have made millions by using these APIs. Smart companies make their APIs mutually beneficial and aren't planning on screwing developers for no reason.

No way (5, Interesting)

thetoadwarrior (1268702) | about 2 years ago | (#38537640)

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.

Re:No way (4, Insightful)

MightyYar (622222) | about 2 years ago | (#38537800)

Like I want to build my software around an API that could disappear in 6 months to a year.

You'd be foolish not to, if you could recoup the investment in less than 6 months to a year with a decent return.

Programmers seem to routinely toss away their entire codebase from time to time anyway.

Re:No way (4, Informative)

betterunixthanunix (980855) | about 2 years ago | (#38537840)

Programmers seem to routinely toss away their entire codebase from time to time anyway.

With disastrous consequences: Netscape, KDE4, etc. Throwing away a large codebase is stupid.

Re:No way (4, Insightful)

Monchanger (637670) | about 2 years ago | (#38538164)

With disastrous consequences: Netscape, KDE4, etc. Throwing away a large codebase is stupid.

That depends very much on the quality of the codebase. They don't age nicely like fine wine, you know.

Re:No way (0)

Anonymous Coward | about 2 years ago | (#38538730)

With disastrous consequences: Netscape, KDE4, etc. Throwing away a large codebase is stupid.

That depends very much on the quality of the codebase. They don't age nicely like fine wine, you know.

That's exactly it right there. Poorly written code doesn't age nicely, well written code is a gift to yourself that keeps on giving many a month down the line

Re:No way (1)

Junta (36770) | about 2 years ago | (#38538656)

Netscape was boned in part *because* of their crappy codebase. They had a hard time making it adapt to new capabilities and evolving standards. In the long run, that has worked well.

With KDE4, I get the feeling that adherents have *mostly* toughed it out and found the end product acceptable. Sometimes to pursue a vision there is a long painful transition, but the end result may be impossible without taking risk.

Re:No way (2)

thetoadwarrior (1268702) | about 2 years ago | (#38538002)

I don't care if I make my money back or not. I don't want to wake up one morning and find my work broken. Most customers wouldn't look favourably towards paying for something that just dies without warning.

Re:No way (1)

Paradigma11 (645246) | about 2 years ago | (#38538156)

So you are going to build your own facebook and then start creating applications for it?
Otherwise, having access to the source wont do you any good.

Re:No way (1)

Dcnjoe60 (682885) | about 2 years ago | (#38538528)

I don't care if I make my money back or not. I don't want to wake up one morning and find my work broken. Most customers wouldn't look favourably towards paying for something that just dies without warning.

So having the source code to FB would solve that how? APIs change far less frequently than the underlying source code.

Re:No way (4, Insightful)

shmlco (594907) | about 2 years ago | (#38538400)

Doing it just because I can "recoup my investment" short term is stupid. Throwing away a large batch of hard won customers is stupid. If I had made a successful ad-supported app with Google Translate, what do I do my customer base disappears because Google closed the APIs? They already had one app from "my" company break. Think they're going to buy another?

Way, way too many companies -- and individuals -- make decisions based on short-term profits, with little to no regard of the long-term impact. That "I'm going to get mine and screw everyone else" sense of entitlement is largely how we got to be in our current mess.

Re:No way (1)

MightyYar (622222) | about 2 years ago | (#38538510)

Doing it just because I can "recoup my investment" short term is stupid.

How is it stupid? You make more money than you started with. Provided the margin is sufficient, it is a smart investment.

Re:No way (1)

Junta (36770) | about 2 years ago | (#38538702)

Most cases I see where a vendor is reliant upon a service they do not control, they make it clear in their branding message. If it should break, they say 'sorry, Google has discontinued this service'. It's not like they'll blame you and *not* your upstream provider. If facebook closed up shop today, no one would be blaming you that facebook doesn't work as the reason will be self-evident.

Either it is something that will be *very* obvious and ubiquitous (like facebook or google+ being shut down) or it's something like google translate, where you can have an alternative backend provider or two to swap in without the users realizing.

Programmers have to cope with this reality *all the time*. It's pretty well a hard requirement when the subject matter is data and userbase held by some entity like Google or Facebook.

Re:No way (1)

Oligonicella (659917) | about 2 years ago | (#38538756)

What did you provide your customer base before the Google app tie-in? Or is your post purely hypothetical?

Re:No way (0)

Anonymous Coward | about 2 years ago | (#38538056)

For example, Google blocked permission MODIFY_PHONE_STATE on Android 2.3+ and 4.0. Before that it was available...

Re:No way (1)

brainzach (2032950) | about 2 years ago | (#38538084)

If you don't want to use their APIs, then you can't use their services to help grow your business and user base.

Technology changes quickly and businesses need to adapt if they want to stay relevant.

Re:No way (1, Interesting)

ArhcAngel (247594) | about 2 years ago | (#38538372)

Hasn't this been Microsoft's business model all along? They release the specs for their API's so third parties can develop for their OS. When a program gets popular enough they clone it and optimize it using undocumented API's and profit?

Puhleez (2, Insightful)

Mathinker (909784) | about 2 years ago | (#38537656)

"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.

Re:Puhleez (1)

Halo1 (136547) | about 2 years ago | (#38538180)

"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.

It's a bit silly to answer the above to an article that ends with

Open APIs are the new open source, except they require less geeky access to lines of code, and more programmatic interaction with software services. As an added bonus, open APIs don't come with the baggage of licensing fundamentalists.

And of course, the main issue the fact that these open api's are very much "here today, gone tomorrow", which is also one of the driving force behind open source development (to reduce a third party's ability to take away features or to make it impossible to keep using some program on newer systems by refusing to update it in case of incompatibilities).

They are not the same thing. (5, Insightful)

El_Muerte_TDS (592157) | about 2 years ago | (#38537658)

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.

Re:They are not the same thing. (1)

punker (320575) | about 2 years ago | (#38537828)

+1 Right on. These are about accessing services, and the data they pump through more than functionality they provide. Open source is still the king of encapsulated functionality.

Re:They are not the same thing. (1)

HarrySquatter (1698416) | about 2 years ago | (#38538076)

Not true as there are plenty of private APIs. Windows, for example, has plenty of them. APIs are not necessarily always for public consumption.

When is this news? (2)

O('_')O_Bush (1162487) | about 2 years ago | (#38537660)

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.

Re:When is this news? (1)

sabs (255763) | about 2 years ago | (#38537714)

Try 1987 :)

Prior art (1)

Anne Thwacks (531696) | about 2 years ago | (#38537664)

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.

Re:Prior art (1)

shmlco (594907) | about 2 years ago | (#38538454)

I think there's a clear and distinct difference between an "Open" API and a "Public" API.

open source is a race to the bottom (0)

alen (225700) | about 2 years ago | (#38537690)

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

Re:open source is a race to the bottom (3, Insightful)

Microlith (54737) | about 2 years ago | (#38538360)

Yes! So instead of a single vendor holding its customers hostage, you get competition that drives down prices and a platform that is independent of the hardware.

That's a good thing. Well, unless you're a monopolistic corporation/control freak.

Reduce revenue... (3, Insightful)

O('_')O_Bush (1162487) | about 2 years ago | (#38537706)

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.

Be Wary (3, Insightful)

samael (12612) | about 2 years ago | (#38537738)

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.

Re:Be Wary (0)

Anonymous Coward | about 2 years ago | (#38537880)

Let's take an example. WOW addons.

Blizzard has rules and restrictions in using them.

Companies and groups that work within them have no objection, there's a fair amount of money involved. Not much compared to the subscriber fees, but still, enough for most people. But Blizzard has changed the rules. Sometimes it was obvious they were doing something to stop an addon that was clearly inappropriate, like original Decursive, or AVR. Other times, it may just be like Carbonite which was obscuring their data sources in order to charge fees to subscribers.

Of course, WOW's API is built around LUA, so if nothing else, you have skills you can use elsewhere, but that doesn't cover the rest of your work. But even if Blizzard never breaks anything, one day they may shut down the World of Warcraft. What then? What then indeed.

But you know what? You could say the same thing about almost any project. Make a utility for Windows, but wait, what if Microsoft implements the feature you're providing? That's happened before. And they could do it without even the questions of the Doublespace situation.

Complications exist in life. Live for the day, don't fear the morrow.

Re:Be Wary (0)

Anonymous Coward | about 2 years ago | (#38538114)

Other times, it may just be like Carbonite which was obscuring their data sources in order to charge fees to subscribers.

Which of course, Blizzard has stated numerous times that people aren't allowed to do, so it's in clear violation of their licensing terms, and is equally "clearly inappropriate" as your other examples.

Re:Be Wary (0)

Anonymous Coward | about 2 years ago | (#38537990)

While web-based apis are particularly dangerous, it's not really limited to it.

In 20 years, VB6 will be the next COBOL.

Re:Be Wary (1)

Dcnjoe60 (682885) | about 2 years ago | (#38538614)

APIs change far less frequently than does the underlying source code. How would having access to the underlying source code mitigate the risk you are talking about? Surely, facebook and google don't just change the API while leaving the source code intact!

Re:Be Wary (1)

samael (12612) | about 2 years ago | (#38538762)

I don't remember saying anything about source code.

Whats Open about APIs ?? (0)

Anonymous Coward | about 2 years ago | (#38537770)

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 ?

Guess not (3, Insightful)

ACE209 (1067276) | about 2 years ago | (#38537804)

Open Source replaced by Open APIs?
How should that work?
Two totally different things.

interesting idea but not FB (3, Insightful)

youn (1516637) | about 2 years ago | (#38537836)

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

Re:interesting idea but not FB (1)

betterunixthanunix (980855) | about 2 years ago | (#38537878)

they don't care about privacy but even they would not do that

You say it as if Facebook has some moral obligation to keep the database secret. They simply do not want to allow their competition to access valuable product data (the product being Facebook users).

Re:interesting idea but not FB (1)

Count Fenring (669457) | about 2 years ago | (#38538398)

They do have legal obligations, actually. Most sites that handle financial transactions do.

It's true! (5, Funny)

Haeleth (414428) | about 2 years ago | (#38537846)

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.

Open APIs renamed: APIs (3, Insightful)

ciaran_o_riordan (662132) | about 2 years ago | (#38537872)

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: []

Re:Open APIs renamed: APIs (4, Insightful)

Nerdfest (867930) | about 2 years ago | (#38538166)

"Published APIs" would probably be a better description for what I think they're trying to say.

Re:Open APIs renamed: APIs (0)

Dcnjoe60 (682885) | about 2 years ago | (#38538634)

"Published APIs" would probably be a better description for what I think they're trying to say.

If I hadn't of already commented, I would mod you up.

Application key (2)

tepples (727027) | about 2 years ago | (#38538718)

"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.

Walled gardens are bad (5, Insightful)

Morgaine (4316) | about 2 years ago | (#38537890)

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.

It's a new game... (3, Insightful)

Junta (36770) | about 2 years ago | (#38538606)

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.

Re:Walled gardens are bad (1)

am 2k (217885) | about 2 years ago | (#38538786)

While you're generally correct, at least in IM a standardization process has been happening. Google, Facebook and MSN have adopted the XMPP protocol [] (RFC 6120) for chatting. Once you have a generic XMPP client, it's easy to connect to those networks (well, some coding is required for MSN and recommended for Facebook to use their oauth implementations, but that's trivial compared to implementing a whole new protocol).

All except Google's are still walled gardens, but I guess that's company policy.

Oh noes! (1)

Orgasmatron (8103) | about 2 years ago | (#38537892)

If only someone [] could have foreseen this and warned you!

Open source was never the way to get rich (4, Insightful)

HuguesT (84078) | about 2 years ago | (#38537900)

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.

And tomorrow (1)

Grindalf (1089511) | about 2 years ago | (#38537904)

Who is to say that these facilities will be around tomorrow - you don't control them and the user does not control or own them. So if I pay for such an application, at a random point in the future it will be stolen from me. Anyone with a solution that works for this? To win, if I buy some software I must still own it and be able to run it in (say) 40 years time ...

'Replaced' (1)

analysethis (868648) | about 2 years ago | (#38537922)

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.

Business model (0)

Anonymous Coward | about 2 years ago | (#38537938)

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.

What is distribution? (0)

Anonymous Coward | about 2 years ago | (#38537954)

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?

Compare Apples and Oranges much? (1)

Idou (572394) | about 2 years ago | (#38537972)

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.

Tone of summary antithetical to article tone (1)

ojintoad (1310811) | about 2 years ago | (#38538046)

I love Slashdot summaries. The very last line summarizes the tone of TFA:

But at the heart of each is APIs. Open APIs are the new open source, except they require less geeky access to lines of code, and more programmatic interaction with software services. As an added bonus, open APIs don't come with the baggage of licensing fundamentalists. Praise the heavens!

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.

Quotas per application (1)

tepples (727027) | about 2 years ago | (#38538736)

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?

Old.... (1)

Darrk Assassin (1461907) | about 2 years ago | (#38538112)

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?

Apples and Oranges (1)

jjh37997 (456473) | about 2 years ago | (#38538124)

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.

#include " proprietary_lib.h" (1)

martijnd (148684) | about 2 years ago | (#38538138)

"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.

Stupid headline (0)

Anonymous Coward | about 2 years ago | (#38538150)

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.

Re:Stupid headline (1)

Dr_Barnowl (709838) | about 2 years ago | (#38538446)

Because the software is running on your server, you are not distributing it, therefore you can even derive your product from GPL licensed code, provide an API, and never have to distribute your source.

Writing your application on top of that means that you relinquish your software freedoms ; you are dependant on an implementation you cannot elect to control for yourself. Which is fine, as long as you are happy with that risk. Most people already do this on their own hardware, so it's not much of a stretch. And software increasingly comes with remotely operable "off switches", so I guess that's equivalent too.

But even proprietary software on your local hardware doesn't require you to deliver your data into the hands of others to make it useful (by design - since it's proprietary you have no easy assurance that it doesn't do this covertly).

An article as thin as air (0)

Anonymous Coward | about 2 years ago | (#38538204)

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.

It's a moot point (1)

Junta (36770) | about 2 years ago | (#38538358)

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.

cretinoid name (1)

mapkinase (958129) | about 2 years ago | (#38538378)

If you can't change API, it aint "open". It's just published.

Comparing apples to oranges (1)

Bananana (1749762) | about 2 years ago | (#38538402)

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?

Open API? - what a dumb name (1)

SpinyNorman (33776) | about 2 years ago | (#38538540)

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.

Problems with OpenAPIs (1)

WOOFYGOOFY (1334993) | about 2 years ago | (#38538788)

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 you define virtual methods, then those methods can call each other in random ways that never get documented AND ALSO other people can override any of those methods. So what happens when you call x, which calls y and then z when someone else has overridden y and z? You have no idea, that's what.

If you use a properties file with a certain name in some location , rest assured developers will find it and add to it. Never mind what you warned them about. It's all going to be charged to your account in the eyes of the users.

Yes there are counter measures you can take. You can attempt to assign fault or blame to fatal runtime exceptions and show who was responsible for that fault to the end user, but it's just going to piss most end users off who barely know what a plugin is, or didn't know their software came bundled with them or whatever, let alone understand that different teams from different companies write different parts of their software.

Backwards compatibility is OK for some thing- those things where you don't HAVE a product unless you offer it- things like runtimes and languages.

No matter what is said, people will still see this as backwards compatibility as a great thing to try and attempt to knock down each problem as it arises. My opinion is, it's not worth it because the time and expense and effort and loss of reputation along the way far exceeds any increased utility gained from plugins.

Make plugin writers update their plugins. Give them advanced notice. If some are AWOL consider writing the the plugin yourself , otherwise, eat it and frustrate some of your users. There was no non-frustrated user path available to you anyway.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account