Slashdot Mirror
Why Open APIs Fall Far Short of Open Source
itwbennett writes "451 Group analyst Jay Lyman opined in a LinuxInsider column that because of open APIs, 'non-open source software is often open enough.' Not so, says ITworld blogger Brian Proffitt. Sure, open APIs are an easy way for a small developer to 'plug into a big software ecosystem,' but it's a trap. 'If open APIs are the only connector to a software project, the destiny of that code lies solely in the hands of the owners,' says Proffitt. 'Which means that anyone connecting into the application will have to deal with the changes imposed from the top down.'"
Google is an expert at this. Convincing people that their open apis are the same as open source. They have and will never opensource their revenue generating products. They themselves don't believe in the open source economic model.
Like for example, the Windows API?
Seems like "Open API" is another way to say "proprietary software."
There's no -1 for "I don't get it."
Because if you code up an "open", gratis API, and it's useful, people will build applications around it. Then, a year later, you start charging for it. Either the developers using your API have to pay or their applications won't work (at least, not without significant recoding, which often means significant developer cost). You're basically holding their code hostage. It's awesome if you're the API developer, of course.
Now, to be fair, this is only unethical if you infer that the API will continue to be free throughout its life. It's certainly not open source though.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
I have nothing against open source, but if an open source product changes its API for some reason, we still have changes imposed from the top down. The only option we have is to then maintain our own version of the opensource project or provide some sort of adapter component. What a headache! I use open APIs all the time. Skype, VST, google, Gracenote being just some of them. Very occaisionally they change - usually for the better due to de-cluttering the API while adding new features. I change my projects and it is rarely a problem. The overhead for doing so is tiny compared to the potential hassle of having to maintain builds and adpaters to potentially dozens of projects just because I want the API to stay exactly the same forever.
You stick your poo in one end, and out of the other end comes rainbows. I assure you there are no hidden APIs or undocumented features. Except for CALEA. Or that thing they are going to require in Canada. Or that thing that we set up with the Chinese Communist Party to promote harmonious communications amongst the people. Or that thing we did for Tunisia back when Ali was in power... anyways.
Open-API is better than nothing. At least you can plug into the proprietary software using a relatively stable interface.
Open source is superior in large part because not only can the small developer use the open API's but actually shape the development of the next generation through direct access to the developers of the API's used and even code contributions themselves. That cannot compare to open API's on a closed source platform.
LedgerSMB: Open source Accounting/ERP
Yep, openwashing strikes again.
'Open API' means something akin to 'documented API' for proprietary software.
I guess more is better. This question is like asking whether you'd like to own a car, or your car AND own the road. Sure, I could then change the rules, and start making a new kind of car. I'd have more control, but to take advantage, I'd have to do a lot more work.
Which means that anyone connecting into the application will have to deal with the changes imposed from the top down.
That holds true only for "cloud" computing, where you have absolutely no control over exactly what happens to the servers, to the applications, or even to your data.
For typical day-to-day applications, including enterprise-level server apps, you absolutely can control what happens, by simply not upgrading to the latest and greatest every three months like the vendor wants you to - And as a rule, you'll find most companies don't do so, staying as far behind the bleeding edge (often two "major" versions) as their service agreement allows.
In larger shops, this happens precisely because upgrading would break any custom in-house apps developed to interface with UberSystem9000. In smaller ones, simply because they don't have the resources to have two people dedicated to nothing but installing service packs 40+ hours a week.
Case in point, you can still find fortune-500s running on an NT4 infrastructure on the server side, and I would dare say the majority of business desktops still run XP.
It's a tradeoff. Open source, Open API - the best choice depends so much on what you're trying to accomplish that I don't see how there can be a general-case answer to that.
If you want complete control, you have to edge toward 100% proprietary code. From there you can compromise toward towing the GPL line, and/or towing the vendor line. Granted, there are other licensing options, but unless you exclude every not-invented-here tool (and maybe that is what you want to do) then there are going to be strings attached.
The author asserts that you "can't live off of" the Open API route - I don't see how he's substantiated that, however. I don't know that you *can*, but we'll find out, won't we? If every Open API oriented business fails, evolution isn't going to run in it's favor.
Comment removed based on user account deletion
*pssst* Wrong story.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
1. Read an article about open APIs.
2. ?????
3. Brian Proffitt
... the question that we need to ask is why Open-Source software often fail to equip themselves with open APIs?
True, some open-sourced software, such as Mozilla Firefox, does offer open APIs to aid independent software developers in writing plug-ins and add-ons.
The problem is, open-sourced software that offer open API like Mozilla Firefox are far and few in between. Many other open-sourced failed to offer such conveniences.
Photoshop won't be so popular without the thousands of plug-ins and add-ons.
On the other hand, how many add-ons / plug-ins are available for GIMP?
For crying out loud, the GIMP authors still refuse users the basic 16-bit per channel support !!
Muchas Gracias, Señor Edward Snowden !
Hey, Whitney, knock twice if you agree with betelgeuse68! ....
I believe the point of open source was so that we could all learn from one another and not reinvent the proverbial corner free rolling device.
API's are an interface, not the procedures that a program follows. This is really an apples to oranges comparison. Maybe the question to ask is, isn't it nice that we can interface with a website as opposed to not?
But we certainly couldn't download the source to Facebook and go start our own myface, with hookers and blackjack!
No, we mustn't assume anything, because TFA (the one who claims open APIs are "open enough") links the term to the Wikipedia page with a definition of open source.
Dilbert RSS feed
I admit that my original piece was a little bit incoherent
Sorry for that
My point being - actually, two points ----
1. Most of the open-sourced software do not offer any open-API
2. Many open-sourced software are purposely constructed as such that they are inferior to their commercial counterparts, and GIMP is a perfect example of that
For point 1. I offer Mozilla Firefox as an example of open-source software that offer open API
However, with the rapid version changes of Mozilla Firefox, many plug-ins that used to work with older version no longer work in newer versions
For users who are accustomed to those plugins, we are handicapped whenever an old trusted plugin can no longer be used
For point 2, how hard is it for the author of GIMP to provide 16-bit per channel support?
How many years already the users clamouring for such feature?
You see any change of attitude from the authors of GIMP in this regard?
No. They, the authors of GIMP, just couldn't give a damn of what the users want.
They just do whatever pleases them, and no giving the users the ability to do 16-bit (or more) per channel support seems to be one of the things that please the GIMP authors
Muchas Gracias, Señor Edward Snowden !
in many cases. Sun was a big Open API company, as was Netscape. They used SMTP and IMAP, HTTP, etc., instead of proprietary protocols. They could possibly add optional extensions, but they certainly couldn't impose change from the top down. Open APIs suggest that the software in question can be replaced and interchanged. One IMAP server can replace another. More specifically, in the Cloud universe this is still true. For example: RackSpace pretty much copied Amazon's cloud storage API exactly.
Having well documented Open APIs is one thing. But until you have open source software, you will never see the undocumented APIs that the owners of the software are keeping hidden to give them an edge. I'd be surprised if Microsoft aren't the only ones who do this.
Neither Open APIs or Open Software in important. What is important is Open specifications and open standards. Too much focus on Open Source I think. I just want open standards and specifications. We can then all bring our own implementations, whether is is proprietary or Open or Free or whatever.
And if it's closed source, AND a security hole is found, you've got yourself in a huge mess, seeing as how you *need* to upgrade to the latest version ASAP, or take the system down.
This can also happen due to compatibilty issues, for example.
I work quite a bit with the YouTube (Gdata) API and have also worked with many Open Source platforms as well. With Open source I am limited pretty much only by my ability in terms of finding out how things work and where the "hooks" are to get the most out of the system. With an Open API such as Gdata I am at the mercy of Google's developers as to what they wish to expose. I can make a request, but good luck with getting it fulfilled if it doesn't fit with their business model.
Some major APIs have slowly become less open. Google once offered a SOAP search API. Then they backed down to their "AJAX API", which could only be used with Google display widgets. Even that's now being shut down. All that's left is "Google Custom Search", which does not allow a general web search.
Twitter once encouraged third party Twitter clients. They no longer do, and they have an authentication system that validates both app and user, so they can yank the credentials of any app they don't like.
The Yahoo search API used to be free, then went to a pay system.
The lesson from this is, don't use an external service API for anything important unless you have a contractual agreement that guarantees that it will stay around.
Except that with an open source project, you can always fork --
In theory, yes.
In practice, the open source project can be so big or so arcane that you are going to need serious muscle and manpower behind you to make it happen.
i do,noting
1. Join ITWorld. 2. Write article. 3. ??? 4. Proffitt!
To the average programmer selling their time/youth to someone in exchange for money, it doesn't matter. The only thing that matters is the job immediately in front of them. Mostly, unless they are wizards at doing product integration, that means closed source with a documented (what the original article is calling "open") API they don't have to relearn every other month to be able to keep working.
There may be tons of people who ARE wizards at doing product integration, but if my experience is any teacher, they aren't the ones writing the package management systems for Open Source OSs or the build management systems for Open Source projects.
IMAP is an open API - truly open, because it's a standard and multiple people support it. RSS is an open API - because I can use an RSS reader with anyone I like.
If an API is only supported by one site then it's still lock-in, and if they change it (or close down, or raise their rates) then you're still fucked.
My Journal
Isn't there a difference between having access to the source code and having access to the data that the source code can deliver (i.e the real value)? (And I'm mainly talking about web-based services here, not OSes or gadgets etc.) Sure, open APIs don't give access to the inner workings of the underlying software, but that's not always a critical factor. The value of having access to the data perhaps outweighs the risk of not knowing exactly how that data is generated. For example, a lot of public utility companies are (finally!) opening up their data to the public so that whoever can build a thingamajig based on public data. The most important thing is that I can get easy access to that data, not neccessarily that I can have full-fethered access to the code behind it. True, non-open software means the We The People have no real insight into HOW that data is crunched or WHAT data gets to be accessible, but that's kinda the situation with any data provider anyway, isn't it?
"Bees!" - Eddie Izzard
"In my experience, it's just as bad, if not worse, developing add-ons for open source projects as it is for open APIs, y _merlin
What open source projects that you have experience writing add-ons for are you referring to here?
Start by hiring one who can move decimal points at will.
I find this thread very strange. The whole point of an API is to hide the implementation details, and the whole point of open source is to expose them. Pragmatically there is no real difference to someone who just wants to use it, if anything I think most developers would just like to see a well documented API regardless of whether the source code is available or not .
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
What took them so long?
Which means that anyone connecting into the application will have to deal with the changes imposed from the top down.
That holds true only for "cloud" computing, where you have absolutely no control over exactly what happens to the servers, to the applications, or even to your data.
For typical day-to-day applications, including enterprise-level server apps, you absolutely can control what happens, by simply not upgrading to the latest and greatest every three months like the vendor wants you to - And as a rule, you'll find most companies don't do so, staying as far behind the bleeding edge (often two "major" versions) as their service agreement allows.
In larger shops, this happens precisely because upgrading would break any custom in-house apps developed to interface with UberSystem9000. In smaller ones, simply because they don't have the resources to have two people dedicated to nothing but installing service packs 40+ hours a week.
Case in point, you can still find fortune-500s running on an NT4 infrastructure on the server side, and I would dare say the majority of business desktops still run XP.
> That holds true only for "cloud" computing, where you have absolutely no control over exactly what happens to the servers, to the applications, or even to your data.
Umm, except for being able to provision exactly the OS you want and install whatever software you want? This cloud FUD is absurd.
Here's an example: Dozens of people built apps that needed permission MODIFY_PHONE_STATE. Then, in Android v2.3 Google blocked it. That made all those apps obsolete. For reference Google: Android MODIFY_PHONE_STATE. I'm hoping someone will eventually come out with a smartphone OS that is truly open source.
I work for a company that OEMs a product with a published API. They make quarterly updates, but here's the rub...
The updates continually update their back-end in non-backwards compatible ways. We end up running multi-cpu days of regression tests to find what's broke and then spend oodles of man-days tracking down what happened and figuring out workarounds each time we try to update. We're still using the API libraries that are many versions before the latest because of this.
At one point I couldn't figure out how to do something with their API,so I requested example code. They sent part of the source a real product that they market that does what I needed. I soon discovered that they don't use their own published interface, completely bypassing the API classes entierly to get to functionality I can't.
I'd take open source over this pain any day.
Umm, except for being able to provision exactly the OS you want and install whatever software you want? This cloud FUD is absurd.
...Until Amazon tells you they can no longer allow you to run Windows-20XX instances because the EU banned its anti-competitive calculator app, and your entire infrastructure depends on a feature basically unique to Windows-20XX.
Lacking control of your own IT assets does not count as "FUD", it counts as a very real business liability.
No, BusyBox cannot force compliance on third party code.
They can force compliance on their code and they can sue for whatever damages they think they can get (or offer any contract that they wish to offer) to redress the copyright infringement of their code.
That could be an offer of "open source all your code", "Your CEO must wear chaps only to work on the next three fridays" or "give me a big car, with shitty mileage", anything.
But they cannot enforce compliance on third party code.
What they CAN do is say that the redress they wish to pay for the criminal actions would be obeying the GPL license of all other code they use. That is merely another contract offer, as enforceable as copyright and a contract.
No, what BusyBox were doing was relying on the termination clause in the GPLv2 - which does not grant you a new license to distribute if you violate it but come back into compliance...
BusyBox were using that little "oversight" to force compliance on third party code before they would grant a new distribution license - otherwise, the party would have no standing at all to distribute BusyBox even after coming back into compliance without BusyBoxes explicit agreement.
It wasn't restitution or redress, it was the fact that the violator completely lost all rights to distribute and would have to find an alternative that BusyBox were using to force compliance on code they had no control over.
Being unable to distribute BusyBox is, in a lot of cases, a fairly significant issue - there is currently no alternative, so you had to bow to BusyBoxes demands to get a new distribution license. Try and continue to distribute, and its trivial to prove that you were doing so without a license.
You are missing the real difference between Open Source and Open API.
Open source allows the developer to dig into the internals of the implementation, modify, and simply take advantage of the knowledge source to enhance debugging, or such like. Open API's allow gives the vendor flexibility to change the implementation without breaking all of the programs written to use the API without explicit internal knowledge of the code.
You can also define an API and deliver source -- as a consumer of the API, this is often the best of both worlds, I can write to the API and get upward compatibility, but use the source to patch or work around bug, debug, etc. accepting the risk of compatibility issues if I rely on the internal source code.
Each method has advantages & disadvantages to the "vendor & developer".
Comparing Linux & MS Windows. Both have API's - The API's in linux are often known as system calls, most developers never change or care about the internals, just that these API's work well.
The problem with API's arise when the API's do not do what you want, either due to defects or simply limits on their flexibility, or vendors decide to drop support or go out of business. API's + plus protect you against this risks, API's without source expose you to considerable risk beyond your ability to control.
Open API is like McDonald's menu.
Casteism
It's not just open APIs this is true of, it's open source itself, of code reuse itself.
The dream is sweet, - "don't write all that code! Save yourself all that work and just hook into THIS code base. The problem is , sure you hooked into that code base and got all that stuff for free but what happens when there's a bug? Does the community fix it right away? Maybe, but only maybe. .. what if they don't and what if the code base requires a huge effort to understand? Now you're screwed and to the exact same extent that you thought you were being given a free ride, except your customers are clammering for a fix and it's all YOUR fault from their POV.
If the sheer mass of code to be considered is big enough and the concepts unfamiliar enough, it's a real barrier to fixing anything. If the owners or acknowledged top dogs of that code base are unfriendly or aloof then so will the user's group be and that's a barrier to comprehension also. If the code base is undocuemnted, then that's something else to think about. We're going through this right now- the company has an open source code base but they're unfriendly, curt, non-responders and so is the UG. Do we decide "meh, we have the source, how bad can it get even with zero assistance ?" or do we decide that it's just not worth the risk and hassle and look elsewhere?
There's a sweet spot to be had between not reinventing the wheel and not being crushed by it.