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."
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
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.
In my experience, it's just as bad, if not worse, developing add-ons for open source projects as it is for open APIs. As much as I hate Windows, it's a good example of a stable API. It doesn't change much, you can keep running old applications, shell extensions, COM modules and whatever else. Open source systems often seem to make incompatible changes at a ridiculous pace that people with plugins are forced to keep up with. Being open source isn't a magical solution to problems. A stable API/ABI is what you want, and it can be delivered, or fail to be delivered,
by open or closed source software alike.
That's an enormous non-sequitur - a single implementation can certainly be open. Just because it's singular does not make it "not open" - that's that attempt to define the term "open" again.
Open does not mean standard, although a standard can be open (or closed), just as an open interface does not necessarily need to be a standard (like GSM or power sockets or RJ45 plugs etc, although it needs to be standardised in that it is relatively unchanging within itself).
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.
Words have meaning, and meaning in particular contexts.
Corporate doublespeak attempts to corrupt that meaning, in this case by intentional reversal; applying a word to it's diametric opposite.
Most people here quite clearly understand that.
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."
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.
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
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.
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.