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.
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.
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
Your point is a good one, especially because hardware like PLCs also depends on interface APIs and hidden IP.
And as stuxnet demonstrated with SIEMENS hardware, yes, not being able to see the internals is a potential problem.
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
GIMP does have open APIs. They have less plugins because they have less users.
Dilbert RSS feed
Your post was confusing. You start by saying that "open-sourced software that offer open API (...) are far and few in between" and then you talk about GIMP, it gives the impression you're giving an example of one of those open-sourced softwares that don't offer open APIs.
Dilbert RSS feed
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.
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.
This is one of the stupidest long winded rants I've seen on here in a while. You should hang out with that apk guy.
The soylentnews experiment has been a dismal failure.
For crying out loud, the GIMP authors still refuse users the basic 16-bit per channel support !!
No they don't.
http://www.gimp.org/docs/userfaq.html#16bit
When can we see 16-bit per channel support (or better)?
For some industries, especially photography, 24-bit colour depths (8 bits per channel) are a real barrier to entry. Once again, it's GEGL to the rescue. Work on integrating GEGL into GIMP began after 2.4 was released, and will span across several stable releases. This work will be completed in GIMP 3.0, which will have full support for high bit depths.
There's also the UFRaw plugin for 16 bit image processing. http://ufraw.sourceforge.net/
"I've got more toys than Teruhisa Kitahara."
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.
No, fuck open api's and open source, and open imolementation. What we need is open architecture and open synergistic competence stacks. Open forward thinking end of day open crowd sourced open revenue open models. Open. Do I win anything?
The soylentnews experiment has been a dismal failure.
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.
don't worry. its just the photoshop fucktards trying to justify paying for software that isn't as good as something available for free
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
For point 2, how hard is it for the author of GIMP to provide 16-bit per channel support?
A sibling points out that this is probably harder than it might seem, and why.
I'll throw my tuppence in and also point out - how hard is it for someone OTHER than the author of GIMP to provide 16-bit per channel support? Because GIMP is GPL software, there are no legal obstacles. The GIMP authors don't even have to like or accept your patches - because the software is GPL, you can distribute a modified version yourself ("HexaGIMP"?), and if 16-bit channel support is the killer feature that all users demand, the original GIMP will rapidly die on the vine.
Hell, put up a Kickstarter project or something. If there are so many users who can't live without this feature, presumably you can get them to pony up enough dollars to pay someone to implement it. Something you'd never be able to do with Photoshop - if Adobe, for much the same reasons as the GIMP authorship team, had insufficient resources to devote to developing a new feature, then you'd either have to i) live with it ii) pester Adobe until they develop it. You don't get option iii) get the feature developed by someone else, and if option ii) does eventually work, you're going to have to pay handsomely to upgrade your software.
"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.
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, 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.