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

Comments

Google

[Anonymous Coward]

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.

Re:Google

[Beelzebud]

Unlike you, who has apparently never heard of something called "Android".

Re:Google

[MyLongNickName]

The OS isn't where they make their money off this product. Being the open source alternative gives them a good market position, but their money is made from selling the hardware and tying it into the other Google services. Think of the OS as the loss leader that gets you in their store.

Re:Google

[exomondo]

You need to read the whole sentence. The OS isn't the revenue generating part of Android. The hardware is. The other Google services are. The open source OS is just the way they get their product (you) and their paying customer (also you but third parties who want your eyeballs) in the door.

You need to read the whole sentence:
That's open source and generates revenue through their ad network.
As you can see i noted the way in which the Android open source software is funded by a profit model that doesn't require the software to be closed, which is very much the open source economic model, which is what i replied to:
They themselves don't believe in the open source economic model.

Re:Google

[Gerzel]

Their top revenue generator is their adds and second indirectly their search engine. Neither of which I'd ever expect for them to open.

Re:Google

[MyLongNickName]

100% agreed. Call it a "loss leader' or the price of doing business, but the OS certainly is not their revenue generator. Amazing how many smart people don't understand how companies make their money.

Re:Google

[DangerOnTheRanger]

Android - at least all the code you get from Google - is under the Apache 2.0 License. That makes Android a fully open-source project, since the Apache License is an OSI-approved license (and quite a permissive one at that). So people can't (or shouldn't) complain about Android not being open-source; they should complain instead about carriers making proprietary extensions. Quick note: CyanogenMod - an open-source build of Android - comes bundled with its own open-source marketplace application.

Open APIs?

[MrEricSir]

Like for example, the Windows API?

Seems like "Open API" is another way to say "proprietary software."

Isn't the problem the same?

[multiben]

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.

Re:Isn't the problem the same?

[betterunixthanunix]

Except that with an open source project, you can always fork -- and if an API change is so drastic that an entire software ecosystem is threatened by it, a fork is likely to happen (or a project may simply maintain two versions -- Apache does this). Firefox has come pretty close, but extension developers do not represent a large enough ecosystem for the community to fork Firefox, and the API changes are not drastic enough to necessitate such a thing.

Re:Isn't the problem the same?

[westlake]

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.

A number of traps actually

[einhverfr]

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.

Re:Would you rather have nothing?

[betterunixthanunix]

I would rather not be at the mercy of Microsoft, Apple, Google, or Facebook. They do not need to change their API, they can just change the licensing and suddenly my software is threatened.

Yeah, real world on line 1? Better than nothing!

[pla]

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.

Re:Well yes

[_merlin]

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.

Re:We should have ask this instead ...

[ozmanjusri]

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/

Slowly closing APIs

[Animats]

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.

Open API is only fine if it's an open standard

[samael]

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.

Re:Open API is only fine if it's an open standard

[Nerdfest]

People keep using the phrase "Open API" where they should be using the phrase "published API". They seem to be trying to make people think that it's something that it's not.

I don't understand

[ggendel]

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.