Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Open Source News

Why Open APIs Fall Far Short of Open Source 163

Posted by samzenpus from the all-due-credit dept.
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.'"
This discussion has been archived. No new comments can be posted.

Why Open APIs Fall Far Short of Open Source More

Why Open APIs Fall Far Short of Open Source

Comments Filter:

  • Google (Score:4, Insightful)

    by Anonymous Coward on Wednesday February 15, 2012 @07:26PM (#39053647)

    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.

    • They have and will never opensource their revenue generating products.

      Of course not, how are they going to make money otherwise?

      They themselves don't believe in the open source economic model.

      errr...Android? That's open source and generates revenue through their ad network.

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

        • Re:Google (Score:5, Insightful)

          by exomondo ( 1725132 ) on Wednesday February 15, 2012 @08:28PM (#39054407)

          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.

        • > The OS isn't the revenue generating part of Android.
          The OS isn't the *direct* revenue part of Android. People don't think they are paying for the OS. However, without the OS you would have hardware with nothing running on it. Just because they don't charge for the Linux or Java (customized versions of which compromise the marketing name, "Android") doesn't mean they don't have value to Google. The OS is very valuable to Google, without an OS they would not make money on this product. Please don't conf

          • It is funny. We agree on all the facts but disagree with the interpretation. I view it as the "loss leader", you view it as part of the whole. Perhaps we simply are viewing the two sides of the same coin. What I won't budge from, however, is that true to the OP, Google will not give away its crown jewels through open sourcing.

        • erm... android is open source SOFTWARE. wtf does hardware have to do with Android being open source or not? wtf does advertising have to do with it? do you people have rocks in your heads?

      • Re: (Score:2)

        by tibit ( 1762298 )

        Google's revenue generating products consist of the service-providing application that runs on Google infrastructure: their data store, indexing, replication, load balancing, configuration/deployment, maintenance front-end, etc. Open sourcing a random Google service would be quite useless: without the infrastructure you couldn't even run the darn thing. You'd have to spend a lot of time implementing at least skeleton functionality of the various back-ends just to run it. And then it'd still be an unscalable

    • Comment removed based on user account deletion

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

        • 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 .
    • Really every API you are stuck to the app that your interfacing with.
      Yes you can adjust an open source app. But really are you going to maintain a fork for a minor to moderate change. For the most part you use the parents software API and you deal with it. If the upgrade breaks what you have your gonna choose to stay with the old version or upgrade and fix your code.
      Really this is just a rant from open source zealots to exaggerate minor trade offs of the models of software.
      • It seems to have attracted a lot of attention from the closed source zealots so I guess it did its job.
      • i think the point is that you have the option to, which means you aren't forced into following what the parent software does (for example, LibreOffice from OpenOffice)

      • OpenAPI doesn't always imply that the original component the API abstracts is available - it's usually the opposite, as OpenAPI typically refers to APIs mediated by remote procedure calls. So if the upgrade breaks your software, you don't get to choose the old version, you have to live with it, even if the changes remove features that your application cannot function without.

        It's easy to see how this might be exploited

        * BigCorp witnesses success of LittleCorp's "SuperThing" project which is based on their B

  • Open APIs? (Score:5, Informative)

    by MrEricSir ( 398214 ) on Wednesday February 15, 2012 @07:32PM (#39053713) Homepage

    Like for example, the Windows API?

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

    • Yep, openwashing strikes again.
      'Open API' means something akin to 'documented API' for proprietary software.

      • Re: (Score:2, Insightful)

        by jo_ham ( 604554 )

        Ah yes, the claim that the word "open" is owned by a small subset of people who think it can only and ever mean "open source software".

        An Open API is just that - an API that is accessible and documented so that if your software wants to work with another piece of software you don't have to reinvent the wheel every time you want to do that.

        Much like an electrical plug and socket being standard - the socket is the API to the power in your house. You are not obligated to use it (feel free to install your own c

        • Your example is great, because that's exactly the point. Like an electrical plug, to be open an API doesn't need to be merely documented - it has to be a standard. Anything with a single implementation is not and can never be a standard, and therefore it's not open.

          • Re: (Score:3)

            by jo_ham ( 604554 )

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

          • So, what, open is a synonym for standard now?

          • case in point... Microsoft Internet Exploder, though I think they are gradually coming around

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

          • Re: (Score:2)

            by jo_ham ( 604554 )

            Yes, words do have meaning, and the term "open" is not solely the domain of open source software, although that is certainly one of several possible uses.

            Most people here clearly understand that, but some people will try to troll as much as possible to muddy the water and claim sole ownership of the word, and that any other use (especially by groups they despise) is some Machiavellian conspiracy rather than the simple use of an adjective that accurately describes the noun it is attached to.

        • So by your logic, why even bother to have dictionaries? Surely formal definitions are just another group of people arrogantly co-opting the language right? Right? The mind boggles.

          • Re: (Score:2)

            by jo_ham ( 604554 )

            Nice non sequitur.

            I did not claim that, and I think you know that (if you really didn't then, goodness, my deepest sympathies). My specific claim is that the term "openwashing" is an arrogant claim on a term used in a derogatory fashion when certain groups who are despised by slashdot use the term in a dictionary-supported manner to describe something. The claim is that the term open has not been correctly applied and is only there to try to add some PR fluff. That's quite clearly not true, but it does tend

        • Why is calling it "openwashing" arrogance? People saying "Open API" are basically saying "an API that we have documented with the intent that a third party may use it".

          This used to be called a "software development kit". Changing the term to "Open API" is an attempt to associate your product with some of the caché of the Open Source movement, without actually doing anything Open Source.

          "Whitewashing" being a term used to denote the representation of an activity in a more positive light that it would

          • Re: (Score:2)

            by jo_ham ( 604554 )

            Because an SDK is often much more than just the API (although it doesn't have to be), and may include multiple different APIs in a widget (that then may also have other non-open APIs, for example, iOS). The descriptor for an open API vs a private one is perfectly apt. SDK and API are not necessarily interchangeable words, although they are clearly strongly related.

            The openwashing term is arrogant because it seeks to claim ownership of the word, or rather, who may use it. For example, the folks on here would

      • 'Open API' means something akin to 'documented API' for proprietary software.

        Yes, that's because "Open" means "Interoperable", which is why "Open Source" and "Free Software" are different things, no matter what the people at the OSI want you to believe about their supposed influence on geek culture, including their supposed right to redefine the English language in their own image.

    • Open APIs are a way to say, "Proprietary software platforms that you can write your own software for!" The word "trap" does not even come close to describing the nature of these systems, which are attempts by certain companies to control large software ecosystems (e.g. what happened with Windows).
      • Open API is just ....an API. I think the issue is with the way people and companies and developers have been talking about web app API's. So it's either a trap (or general foul play) or just a term that is coming into the vernacular of the internets. Which is more important of an issue though is my question. Companies being bad? or people calling things by different(misleading) names?

    • Re: (Score:2)

      by tibit ( 1762298 )

      That's like "open" industrial standards, like, um, CiP - common industrial protocol, developed by ODVA [odva.org]. It's "open" in the sense that if you pay them a couple thousand bucks and agree to all sorts of things, they'll politely let you read the freaking thing. Pretty steep for an "open" standard, if you ask me. And designed by a committe that must have had a couple armchair politicians included, because boy, did they overengineer that thing.

    • However the summary is a bit more dire than is probably what happens. If an API changes then there's a big chance you lose a lot of customers or customers refuse to upgrade, or your partners stop being your partners. Maybe Microsoft doesn't care about this but smaller companies are concerned and will do what they can to keep the APIs backwards compatible.

      For instance at once company I was at I worked on the external APIs to the main product which allowed third parties and customers to integrate it with ot

      • Maybe Microsoft doesn't care about this but smaller companies are concerned and will do what they can to keep the APIs backwards compatible.

        I can't think of a single vendor that's bent over backwards more than MS to keep their APIs backward compatible -- the fact that Windows 7 can run applications from the 80's is a testament to that.

  • 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

    • Re:Well yes (Score:5, Insightful)

      by _merlin ( 160982 ) on Wednesday February 15, 2012 @08:03PM (#39054109) Homepage Journal

      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.

      • Has it occurred to any of you open API vs source jokes that you are talking about two completely different things? Software can be open or closed with or without api's. Duh. What the hell is wrong with you people?

      • In my experience, it's just as bad, if not worse, developing add-ons for open source projects as it is for open APIs.

        Really? Open APIs are prbably the best thing, better even than OSS. I don't count a documented proprietary API as open.

        Open APIs are things like OpenGL, POSIX, standard libraries (e.g. C and C++), OpenMP, MPI etc. These are all documented by some standards organisation and there are multiple implementationsboth closed and open. To a large extent (especially these days), you can write once and

  • Isn't the problem the same? (Score:5, Insightful)

    by multiben ( 1916126 ) on Wednesday February 15, 2012 @07:37PM (#39053763)
    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? (Score:5, Insightful)

      by betterunixthanunix ( 980855 ) on Wednesday February 15, 2012 @07:50PM (#39053921)
      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? (Score:5, Insightful)

        by westlake ( 615356 ) on Wednesday February 15, 2012 @08:15PM (#39054253)

        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.

        • Re: (Score:2)

          by Korin43 ( 881732 )

          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.

          Something big and arcane like OpenOffice or XFree86?

          • Yes, of which neither could have been forked by a single developer or even a small group of developers. They are on the other hand given lots of development through paid developers.

          • I think you proved his point for him. Yes.

      • You can often do something similar with a proprietary system - just keep running the old version. Yeah, you can't maintain and update it yourself, but with an Open Source project of even moderate complexity, only a very very few of its users are going to have the expertise to maintain and update a fork in the first place. It's a theoretical advantage for Open Source, but I imagine it would be realized only very rarely.

        • Unless you pay a programmer to do it for you. The problem with closed source is you can't hire someone and tell them

          "Here's $100, go sit in Microsoft's building and recompile their code with a couple of changes, just for me"

          • And have the expertise and time to manage the programmer. Sure, for a minor feature here and there, one that's simple enough for a non-techie to spec and test themselves, sure, a short-term contract's fine (although I doubt you'd get much done for $100). But if you're looking at anything more than that, you're going to be employing someone for weeks or months, plus testing, scope and management overheads. A big company can probably throw money at their IT department, and get them to manage a couple of contr

          • Unless you pay a programmer to do it for you. The problem with closed source is you can't hire someone and tell them "Here's $100, go sit in Microsoft's building and recompile their code with a couple of changes, just for me"

            So you can pay a programmer $100 to build a new version of OpenOffice for you with a few changes? Where do you find programmers that cheap?

        • Assuming you can still license the old version...

    • 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!

      Think of open source as insurance against sudden changes. You can maintain your own version for as long as you need to move to the new API, thereby being less disrupted. Without this option of open source, you get

      • You can maintain your own version for as long as you need to move to the new API, thereby being less disrupted.

        Unless you are writing toy programs, almost no one has the ability these days to take on the role of maintaining every piece library or API that they rely on. So, no, you are just as disrupted because then you now have to get up to speed on the source code of each of these pieces you have to maintain which depending on what the library/API/etc is can be a monumental task. Far more painful than just adapting to the API change.

        • Where did the Ggp say anything about maintaining every library he relies on? He said go that route as a last resort while adapting to the new API. Where do you put all the straw men you build because you have quite a collection going from this thread.
  • Open-API is better than nothing. At least you can plug into the proprietary software using a relatively stable interface.

    • Re:Would you rather have nothing? (Score:5, Insightful)

      by betterunixthanunix ( 980855 ) on Wednesday February 15, 2012 @07:51PM (#39053961)
      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.

      • Then don't use their offerings.

        Oh wait, didn't a Sony employee recently get run out of Slashdotville because they no longer wanted to rely on BusyBox and intended to replace it with something they could control? I distictly remember a lot of derision about his plans...

        • Oh wait, didn't a Sony employee recently get run out of Slashdotville because they no longer wanted to rely on BusyBox and intended to replace it with something they could control?

          No, they wanted to build an alternative based on a different license because people keep forcing vendors to stick to the terms of the GPL for busybox and in fact use that as a hook to force them to stick to the terms of the GPL for all the softwar ethat they ship.

          In other words, the guy basically wanted te be able to break other p

          • So yes, it was something they could control, and not fall under the control of someone else.

            My point precisely.

            • My point precisely.

              Well, that was a little ambiguous to say the least. The entire thread is about the API and source level control. As far as I know the Sony guy had no complaints about Busybox, or the direction it was going or the feature set in terms of source and features.

              It wasn't clear to me that "control of the source" was equivalent to "being able to infringe a bunch of unrelated licenses with impunity".

  • A number of traps actually (Score:5, Interesting)

    by einhverfr ( 238914 ) <chris DOT travers AT gmail DOT com> on Wednesday February 15, 2012 @07:38PM (#39053779) Homepage Journal

    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.

  • Yeah, real world on line 1? Better than nothing! (Score:4, Insightful)

    by pla ( 258480 ) on Wednesday February 15, 2012 @07:54PM (#39053999) Journal
    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.

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

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

  • Slowly closing APIs (Score:5, Insightful)

    by Animats ( 122034 ) on Thursday February 16, 2012 @01:22AM (#39056599) Homepage

    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 (Score:5, Insightful)

    by samael ( 12612 ) * <Andrew@Ducker.org.uk> on Thursday February 16, 2012 @04:38AM (#39057463) Homepage

    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.

  • I don't understand (Score:3, Interesting)

    by ggendel ( 1061214 ) on Thursday February 16, 2012 @10:15AM (#39060057)

    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.

Slashdot Top Deals

Every nonzero finite dimensional inner product space has an orthonormal basis. It makes sense, when you don't think about it.

Close