Open Source Increasingly Replaced By Open APIs 224
SharkLaser writes "Open APIs might be the way to get rich in 2012. At the same time, it can also be what ultimately hinders open source development. A wide range of companies, including Google, Facebook, Amazon and Twitter, are building open APIs for other developers to use and build upon. Open APIs can be used by companies to grow their user base and introduce new, interesting features on top of their platform. Independent developers can utilize established services and their users to grow their own business. A perfect example of open APIs is Facebook Apps, which lets individuals and companies develop applications and games on top of the Facebook platform. Developers gain access to Facebook's established user base and Facebook gains new features and fun stuff to do on their site. Instead of open sourcing their platforms, companies like Google and Facebook are providing Open APIs and data access to outside developers. The actual source code for the services sits safely inside the company's network and never needs to be disclosed to outside parties, thus hindering open source development."
What's the point? (Score:3, Insightful)
What's the point of opensourcing Facebook? It's the userbase that matters to web-developers, not the server code.
Re:What's the point? (Score:4, Insightful)
On your race to the First Post you completely missed the point. Hell, you even missed the headline!
Re:What's the point? (Score:5, Insightful)
Actually.... the summary does mention that the lack of open source code from Facebook and Google is "hindering open source development."
He may be question the usefulness of Facebook being open source and why would it "hinder" anything.
Still a flawed observation that I replied in another post, but at least it seems he did read enough of the summary (i.e. all of it, not just the title) to jump to his argument.
Re: (Score:2)
Actually.... the summary does mention that the lack of open source code from Facebook and Google is "hindering open source development."
Ah yes, Facebook [facebook.com] has really waged a war on Open Source by not releasing code, eh? And don't get me started on those bastards at Google [google.com].
Re: (Score:2)
Ehm.... I already stated that... and it's what I was refering to by saying "Still a flawed observation that I replied in another post"
Re: (Score:3, Insightful)
Re:What's the point? (Score:4, Insightful)
"Lets be honest folks we ALL know what is causing this, hell its the same thing that is causing the drop in GPL code we saw posted here a little while back, and that is this: RMS went too damned far with GPL V3 and this is the backlash."
Complete nonsense. Furthermore, the whole idea about open source is to control the destiny of your investment, customer base while at the same time allowing customers to partcipate as engineers, not just as end users in what amounts to a community which has the final say as to what changes are made to the software it uses, and even if the software will continue to be used for a given purpose.
That result is open source. Open API's are not open source. No, if I have an open API it is not going to allow my customers to participate as engineers, it will not allow the community to control the destiny of the softwar either.
Those API's could be removed tomorrow, you can't improve them, the bugs are intractable or ignored by the corporate Big Brother who is monitoring everything you are doing with those API's.
Are you people just plain stupid or have you had your heads in the sand since 1992?
How can someone post something like this and get a Score 5 as insightful?
Go ahead and embrace your open API's.
You probably enjoy TSA sticking their hands down your kids pants, why wouldn't you enjoy having someone monitor every API call your software does.
F'in diots I hope you get the world you deserve.
You don't deserve Stallman's vision or any sort of Freedom!
-Hack
Re: (Score:3, Informative)
Reference implementation (Score:2)
Re:What's the point? (Score:5, Interesting)
There is a lot of point. Few online services can handle the level of activity Facebook handles every minute. It's not just about tossing more hardware at it either; it's not easy to make such a scalable system.
Open sourcing Facebook gives developers access to the custom code that allows them to handle all this, making it easier for small startups to jump into large service hosting solutions.
Also, not sure what the summary means with the last statement. It is my understanding that Facebook HAS open sourced their server code (very likely as a jab at Google who, despite being "Open" would never dare give any competitor access to their scaling server code.)
Re:What's the point? (Score:5, Insightful)
It’s sad that anyone who makes a web service thinks they don’t have to, and as soon as they get 10 more users than they tested their service with the entire thing falls apart and they can’t scale it up to manage users. All they can think of is to try to optimize code here and there, but that has its limits and eventually you will need a system that can handle the scaling demand.
“Scalability” is not about being able to “be as big as facebook”, it’s about being able to handle increased user demands, be it seasonal or popularity based.
Re: (Score:3)
Re: (Score:3, Insightful)
Re: (Score:3)
What's the point of opensourcing Facebook? It's the userbase that matters to web-developers, not the server code.
It's all about forking. Everyone on Facebook is all about forking too, but that's not what I mean ;-) If Facebook retain control of the code, they can choose to make whatever changes they wish and users will never defect to a competing network. If they open sourced, Microsoft for example could fork it and include it as a feature of Hotmail - okay not the best example but you get what I'm saying. Take an existing user base and hijack/poach Facebook users.
I see no problem here. (Score:5, Insightful)
Re:I see no problem here. (Score:5, Insightful)
Re:I see no problem here. (Score:5, Interesting)
The problem is that web app APIs can change at a moment's notice, without any announcement, and all the developers who depended on the API will be left out in the cold.
While that's true, if they do it too often and to too great an extent they'll lose developers to some other platform; if the apps start breaking without replacement, users will start to leave for other sites. Facebook (as big as it is) is nothing without its userbase.
Re: (Score:3)
Except doing such a thing would drive away the very developers they are trying to bring in thus would kill their site.
Re:I see no problem here. (Score:5, Insightful)
While you in particular may not necessarily have a use for the source code, the point is that it is unavailable to those who do wish to use it. The "use" might be understanding what it is doing (what information is it sending to the parent company), modifying it (so that it does not do this), and having the ability in principal to continue to run the API (modified to run on your own or an alternate social network) if the site owner goes out of business, does things you don't like with the information you give them, or decides to ban your application.
Re:I see no problem here. (Score:5, Insightful)
> So why would anyone care about Linux?
People care about Unix and Linux is just another Unix.
THAT is what freely re-implementable interfaces get you. Now while it is possible to have proprietary interfaces that can be re-implemented, it is very rare. The whole point of "owning" the API is the fact that you can disallow drop in replacements. You are you're own monopoly and market pressures quickly enforce that.
We haven't moved from Free to Proprietary but from proprietary apps to proprietary services where all of your eggs are in one basket at some Facebook owned data center.
What's missing is mobility of data between different "compatible" services.
Re: (Score:3)
WINE implements the same APIs as Windows and several commercial products have shipped non-Windows versions by either compiling against winelib or just shipping a WINE wrapper. The idea in US copyright law that you can't copyright an interface means that any API is freely reimplementable (unless it is covered by patents, although patents cover implementations so are more likely to affect ABIs than APIs).
The advantage of owning the API (which really just means owning the most popular implementation of the
Re: (Score:2)
Embrace the power of AND.
I want....both! (I also want it immediately for no cost, but thats just typical isn't it?)
Seriously though, the source availability may not be of use to you now, directly but, if you don't think it is of use to you, then realize that if the service with the published API goes away, you don't have a starting point to replace it, other than the API docs... unless someone else already implemented another version off the same docs.
There are definite plusses to independent code bases...
Re: (Score:2)
Yes but, you are thinking in terms of a developer. its true, API docs are a great starting point, and if well done, will allow you to recreate the whole API from scratch.
Now.... its friday at 6 pm. Your companies bread and butter is an app that was built on top of an API run by a company that just shuttered its doors forever.
If that API was based on open source, then you may have a few hours, or a day or so getting dependencies, looking over docs, getting it installed. Hell, if its really complicated, maybe
Re: (Score:2)
Right I never said that your app and its requirements can't be complex as to make this infeasible. However, not every app is in that situation. Not everything runs on google or facebook or uses their specific APIs.
Yes, its entirely possible that this is the case. However, in any case, rebuilding without the original players is generally going to be easier and faster with the source available.
Clearly, in the high volume world of 5-20k hosts per admin, this may not matter so much. The idea that anything that
Re: (Score:3)
And how many times in your long programming career have you delved into the bowels of the Linux source to build a better *nix application?
Speaking as a driver/kernel developer: on a very regular basis. Maybe not daily, but certainly several times a week.
Sure, if you're a web developer, or work up in user space, you may not need to do this - but the reason that the web works as well as it does is because the low-level support is there, works well, and works efficiently. So the success of your application depends in part on the source being open, even if you never look at it yourself.
Open API? (Score:4, Insightful)
Re:Open API? (Score:5, Interesting)
Re:Open API? (Score:5, Insightful)
Another way of phrasing it (which I remember being used in the context of Microsoft's API): "software sharecropping."
I don't know why this is marked flamebait. I think the comment is rather astute.
What is the point in building code to support a library that puts you in a position wherein you immediately become dependant on something you cannot control. Resulting in a product that largely makes money for someone else.
That's not flamebait, it's wisdom.
Re: (Score:2)
you know what's the only api product I used that did that?.. google api(for the search, back in the day). 1000 queries free per day.
Re: (Score:2)
What is the point in building code to support a library that puts you in a position wherein you immediately become dependant on something you cannot control. Resulting in a product that largely makes money for someone else.
Many developers have made millions by using these APIs. Smart companies make their APIs mutually beneficial and aren't planning on screwing developers for no reason.
Re: (Score:2)
Re: (Score:3)
When you hear "Open API" any programmer will think it just means a well-known or documented API; i.e. it's not a secret. Load the accumulator with the petscii character you want to output and JSR $FFD2 -- or make a certain REST call as documented at the service's site -- that's what people will think you're talking about, when you say "Open API."
That isn't what TFA is talking about.
He's talking about different services using the same APIs, being client-compatible. That is, if you make a competitor to AWS,
No way (Score:5, Interesting)
Re:No way (Score:5, Insightful)
Like I want to build my software around an API that could disappear in 6 months to a year.
You'd be foolish not to, if you could recoup the investment in less than 6 months to a year with a decent return.
Programmers seem to routinely toss away their entire codebase from time to time anyway.
Re:No way (Score:5, Informative)
Programmers seem to routinely toss away their entire codebase from time to time anyway.
With disastrous consequences: Netscape, KDE4, etc. Throwing away a large codebase is stupid.
Re:No way (Score:5, Insightful)
With disastrous consequences: Netscape, KDE4, etc. Throwing away a large codebase is stupid.
That depends very much on the quality of the codebase. They don't age nicely like fine wine, you know.
Re: (Score:2)
Netscape was boned in part *because* of their crappy codebase. They had a hard time making it adapt to new capabilities and evolving standards. In the long run, that has worked well.
With KDE4, I get the feeling that adherents have *mostly* toughed it out and found the end product acceptable. Sometimes to pursue a vision there is a long painful transition, but the end result may be impossible without taking risk.
Re: (Score:3)
Re: (Score:2)
So you are going to build your own facebook and then start creating applications for it?
Otherwise, having access to the source wont do you any good.
Re: (Score:2)
Re: (Score:2)
I don't care if I make my money back or not. I don't want to wake up one morning and find my work broken. Most customers wouldn't look favourably towards paying for something that just dies without warning.
So having the source code to FB would solve that how? APIs change far less frequently than the underlying source code.
Re: (Score:3)
So having the source code to FB would solve that how? APIs change far less frequently than the underlying source code.
Unless we're talking about Linux ;)
Re:No way (Score:5, Insightful)
Doing it just because I can "recoup my investment" short term is stupid. Throwing away a large batch of hard won customers is stupid. If I had made a successful ad-supported app with Google Translate, what do I do my customer base disappears because Google closed the APIs? They already had one app from "my" company break. Think they're going to buy another?
Way, way too many companies -- and individuals -- make decisions based on short-term profits, with little to no regard of the long-term impact. That "I'm going to get mine and screw everyone else" sense of entitlement is largely how we got to be in our current mess.
Re: (Score:2)
Doing it just because I can "recoup my investment" short term is stupid.
How is it stupid? You make more money than you started with. Provided the margin is sufficient, it is a smart investment.
Re: (Score:2)
Re: (Score:2)
Most cases I see where a vendor is reliant upon a service they do not control, they make it clear in their branding message. If it should break, they say 'sorry, Google has discontinued this service'. It's not like they'll blame you and *not* your upstream provider. If facebook closed up shop today, no one would be blaming you that facebook doesn't work as the reason will be self-evident.
Either it is something that will be *very* obvious and ubiquitous (like facebook or google+ being shut down) or it's s
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The business answer is that as you recoup your investment, you re-invest in diversifying. Using your Google Translate example, you search out alternatives and build code to be able to share or shift load off of Google's service. Similarly, if you are "freeloading" off of Google's service, you need to plan that eventually you may need to pay for that functionality and build it into your business model.
Re: (Score:2)
If you don't want to use their APIs, then you can't use their services to help grow your business and user base.
Technology changes quickly and businesses need to adapt if they want to stay relevant.
Re: (Score:2, Interesting)
Puhleez (Score:2, Insightful)
"hindering open source development"?
Yeah, sure. Just like the fact that I, like most people, don't donate 10% of my income to the FSF or some other open-source project hinders it. So what?
If you want to judge others from a particular ideological position (concealing code is unethical), you should state that clearly rather than impugn others indirectly.
Re: (Score:2)
"hindering open source development"?
Yeah, sure. Just like the fact that I, like most people, don't donate 10% of my income to the FSF or some other open-source project hinders it. So what?
If you want to judge others from a particular ideological position (concealing code is unethical), you should state that clearly rather than impugn others indirectly.
It's a bit silly to answer the above to an article that ends with
Open APIs are the new open source, except they require less geeky access to lines of code, and more programmatic interaction with software services. As an added bonus, open APIs don't come with the baggage of licensing fundamentalists.
And of course, the main issue the fact that these open api's are very much "here today, gone tomorrow", which is also one of the driving force behind open source development (to reduce a third party's ability to take away features or to make it impossible to keep using some program on newer systems by refusing to update it in case of incompatibilities).
Re: (Score:2)
Except for the fact that these Open APIs are built on top of Open Source. Facebook uses PHP and has contributed back code that improves performance. Google are using Linux internally with their own Google File System and BigTables. Other web services are using NoSQL and LAMP stacks.
An "Open API" would allow an open source application to use that API. If it does not, it cannot be called an "Open API" as it is restrictive in what you can use to interact with it. It is rather a "Public API" that is documented
They are not the same thing. (Score:5, Insightful)
Most of these APIs provide access to data "owned" by the providers of those APIs. They rarely ever provide functionality that is not coupled to their data. These Web APIs are not going to replace open source tools/libraries that provide functionality.
Also, using the term Open API is bullshit. First of all, an API is pretty much always open otherwise it cannot be an "application programming interface". If the API was closed it would not even be an interface to program against but a blackbox.
Re: (Score:2)
Not true as there are plenty of private APIs. Windows, for example, has plenty of them. APIs are not necessarily always for public consumption.
When is this news? (Score:3)
I don't see how this is news, or how these APIs wiill suddenly make companies rich in 2012... when the APIs have been around since at least 2007.
Re: (Score:2)
2007? :)
Try 1987
Prior art (Score:2)
Re: (Score:2)
I think there's a clear and distinct difference between an "Open" API and a "Public" API.
off by a few decades (Score:2)
Reduce revenue... (Score:4, Insightful)
2. Don't require ads or developer fees
3. ???
4. Profit?
I would have written more, but I think that sums up my point.
Be Wary (Score:4, Insightful)
Many companies have built their products on top of someone else's APIs, to have those APIs change, vanish, or develop charges later on. Do be aware of the pitfalls before you make yourself totally dependent on someone who does not have your best interests at heart.
Re: (Score:2)
APIs change far less frequently than does the underlying source code. How would having access to the underlying source code mitigate the risk you are talking about? Surely, facebook and google don't just change the API while leaving the source code intact!
Re: (Score:2)
I don't remember saying anything about source code.
Re: (Score:2)
Let's take another example - Google Maps:
http://www.bbc.co.uk/news/business-15523050 [bbc.co.uk]
or Google App Engine:
http://www.informationweek.com/news/cloud-computing/platform/231600672 [informationweek.com]
Guess not (Score:3, Insightful)
How should that work?
Two totally different things.
interesting idea but not FB (Score:4, Insightful)
I do think Facebook is a bad example. Their API is open and the SDK is open too... yes, the code is executed remotely... but that is the whole point because it interacts with the user data... that is the beauty behind technologies like XML-RPC or soap... good luck to facebook opening up access to their whole database... they don't care about privacy but even they would not do that
now, it is true that a lot of companies provide an open SDK with a binary part... a good example would be video drivers which are open source yet include a binary part that is not open source. Games are another example.
Even then, I would still consider it progress because before that there was no SDK, the only way to modify existing products was through a hex editor... at least now, software editors provide an api to interact.
The concept is not even new... windows operating system is based on binary DLLs that many times only microsoft has the source code... yet visual studio comes with sourcecode and a very complete toolkit... but even that was not the first time open api was provided to a binary core... I guess that is just the way software is done
Re: (Score:2)
they don't care about privacy but even they would not do that
You say it as if Facebook has some moral obligation to keep the database secret. They simply do not want to allow their competition to access valuable product data (the product being Facebook users).
Re: (Score:2)
They do have legal obligations, actually. Most sites that handle financial transactions do.
It's true! (Score:5, Funny)
For example, just this morning I replaced Debian on my computer with the Twitter API. It works great, boot times are much faster. Now I'm going to uninstall Firefox and just access the web via the Facebook API.
Open APIs renamed: APIs (Score:4, Insightful)
It's an API. Tacking "Open" onto doesn't change the fact that it's just an interface to a black box.
As Stallman's been saying for the last few years, having software freedom is about having control over your computing, and that requires that your computing is done on *your* computer:
http://www.gnu.org/philosophy/who-does-that-server-really-serve.html [gnu.org]
Re:Open APIs renamed: APIs (Score:5, Insightful)
Application key (Score:3)
Walled gardens are bad (Score:5, Insightful)
Remember the good old days of the Internet, in which techies used to invent useful protocols, document them as RFCs, and then the best of these would be turned into Internet standards at the IETF? That approach gave us an open Internet with multiple implementations of the same standard services, all competing on merit not through proprietary lock-in.
Well that's not where we are today. Instead we have a ton of proprietary services that occasionally publish public APIs when it suits them, but they're almost always pathologically opposed to interoperating with anyone else that might provide competition. Imagine a world in which everyone used their own homegrown mail prototols instead of SMTP and POP or IMAP. That's where we are today with the social networking services.
Walled gardens are bad. Publishing open APIs doesn't make them any better, as the gardens are still walled and these closed services reject federating with other similar ones. And even if they accepted federation, the complexity of a fully interconnected graph in which each node has a different public API grows explosively, so technically this is a very bad design approach.
Things aren't at all healthy on this front of the Internet, and proprietary services having open APIs doesn't help much. The best that can be said is that it's a bit better than no API at all, but that's not saying much.
It's a new game... (Score:4, Insightful)
Assuming there *was* one universally accepted standard that Facebook embraced and was also implemented by MySpace. No one would still give a rat's ass about MySpace. The APIs in this case are trivial and you can make up your own or copy them as a de-facto standard, but the data and user connectedness that the service embodies is what matters.
There are two good reasons these companies don't go through RFC process for things like this. One, as above, the APIs are trivial and only of value to their data so an RFC process makes no sense. Secondly, if they were married to the RFC process, every little enhancement has the potential of taking months to over a year to ratify. Nothing is stopping a community for creating an RFC to compete with a proprietary API and if you push it through and are successful and create an ecosystem, then Facebook might implement it on top of their proprietary API.
Incidentally, the same phenomenon can be seen in the 'good old days' of the internet. Cisco frequently did (and still does) roll out a proprietary protocol and when the IETF finally ratifies a standard to do the same thing, Cisco implements the standard as well as their proprietary approach (ususally, some times Cisco ignores the standard, probably due to lack of explicit customer request). Also, at the upper layers, there is a large precedent for people not bothering with RFCs at all. As far as I know, there is still no IETF RFC covering bittorent. There we have a very popular, community driven technology that has been in use for years that doesn't bother with IETF RFC process.
Ok (Score:2)
I retract my criticism, I somehow completely missed the point about federation and assumed someone was oversimplifying the situation (as the original article did). Of course, open source is orthogonal to this (this thread hasn't brought it up, so I think that's well understood), you have to modify the behavior of Facebook, not have read access to their source.
Re: (Score:2)
While you're generally correct, at least in IM a standardization process has been happening. Google, Facebook and MSN have adopted the XMPP protocol [xmpp.org] (RFC 6120) for chatting. Once you have a generic XMPP client, it's easy to connect to those networks (well, some coding is required for MSN and recommended for Facebook to use their oauth implementations, but that's trivial compared to implementing a whole new protocol).
All except Google's are still walled gardens, but I guess that's company policy.
Re: (Score:2)
So apart from the fact they're walled gardens, each implement a different subset of the standard that corresponds to whatever actual underlying protocol they use, and (in the case of MSN and Facebook) have their own authentication system that no-one else uses, in theory with a good wind behind you they can actually be connected to with some of the same code.
Re: (Score:3)
So apart from the fact they're walled gardens, each implement a different subset of the standard that corresponds to whatever actual underlying protocol they use, and (in the case of MSN and Facebook) have their own authentication system that no-one else uses, in theory with a good wind behind you they can actually be connected to with some of the same code.
Well, yes :) Still, it's much better than what has to be done for other [khstu.ru] protocols [blackhat.com].
Oh noes! (Score:2)
Open source was never the way to get rich (Score:5, Insightful)
I'm not sure what the point of the submitter is. Open source and open API have little in common. It's not like one could develop an OS kernel based on some documented open API. Open API is also nothing novel.
Getting rich as an individual is not the point of Open-Source. Getting richer as a software-building community in terms of software availability is.
Re: (Score:2)
It's not like one could develop an OS kernel based on some documented open API.
One of the first design goals for Linux was following POSIX, even though the standard was too expensive for Linus [linuxjournal.com]. While standards like POSIX and TCP/IP don't directly state how an OS kernel must be written, wanting to comply with them does shape the basic form the kernel needs to take.
If you read the Tanenbaum-Torvalds Debate [oreilly.com] thread, one of the recurring themes there is that even having easily available source code (as MINIX did) isn't enough. One of the necessary components to growing a software communi
Compare Apples and Oranges much? (Score:2)
Tone of summary antithetical to article tone (Score:2)
Emphasis Mine.
There's a lot of places to come down on this. I develop with Google Apps, which leverages a lot of Open Source software in order t
Quotas per application (Score:2)
Re: (Score:2)
Apples and Oranges (Score:2)
Companies offering Open APIs are not hindering open-source developers.... Open APIs remove barriers for all software developers and allows them to make interesting products. What hinders open-source developers is other developers keeping their source code closed.
#include " proprietary_lib.h" (Score:2)
"Open" API's are the new include files to proprietary libraries.
At least in the good old bad days the library (usually) didn't stop working after the you compiled & distributed your program.
These days.. no such guarantees.
It's a moot point (Score:2)
For the *most* part, the technical capabilities of sites like Facebook isn't the impressive thing. At small scale, anyone can make code to function well in that capacity. If your endeavor grew to the point that facebook does, you'd have the resources to do the harder, but not impossible part of making that stuff scale. These sites are not succeeding because of inherently superior technology, they are succeeding by knowing exactly how to draw everyday users into a platform. What philosophy to embrace (e.
Re: (Score:2)
I will revise my statement because someone else pointed out the theoretical answer. Services like Facebook would have to be federated, meaning Facebook would either have to die or change it's behavior, which is unlikely.
Of course, that's the social networking case, still no answer on things like most of Google's non-social capabilities.
cretinoid name (Score:2)
If you can't change API, it aint "open". It's just published.
Open API? - what a dumb name (Score:2)
An API is just an interface - there's nothing inherently open or closed about it. The code behind the API might be either open source or closed source, and in this case we appear to be talking about closed source.
Not only is open vs closed a meaningless adverb to apply to an API (the closest concept might be public vs private - e.g. hidden Winodows API's), but the trend the article is attempting to discuss is the growth of cloud based platforms - i.e services made available via web services (SOAP, .NET, etc
Re: (Score:2)
Re: (Score:2)
Undocumented != Closed, and anyways you can certainly write apps to undocumented APIs if you can figure/reverse engineer what they do.. but you'd generally be unwise to as undocumented typically also means unsupported so they may disappear without warning in a subsequent release.
The article anyways isn't talking about documented vs undocumented - they are struggling for the right words to describe the trend towards "platformization" of web based products - exposing their functionality via web-services APIs
A Serious Question (Score:4, Interesting)
As a software developer this is a serious question for me and one that I've never gotten a satisfactory answer to.
How can I feed my family or control my own destiny if the software is all I have? Am I not dependent on the benevolence of a corporation or university to fund my project or work as a clerk or something during the day and code at night? I know Open Source companies can make money on services or hardware but I'm not an Open Source company, I'm just one guy trying to make a living. I don't have the capital to produce hardware and my software is designed for end-users who don't require much in the way of services.
If I were working on some glue code that might be useful to other developers and where I would benefit from their contributions I certainly would open source it (and I do contribute patches to some of the open source projects I use). I also get the idea of an open source OS or other large projects because so many companies depend on it there are enough "payers" in the pool to fund a lot of full-time devs - more than enough to cover the people who make millions off it (eg: Linux) yet contribute nothing back... plus with millions of users you have enough part-time tinkerers that you also get significant contributions from them.
But I just don't see why I would open source my apps. No company in the world can pay my salary based on them, yet there are thousands of users willing to pay $0.99 for them, enough that I can keep my hardware up to date and have a little bit left over to go out to eat every month (certainly not enough to quit my job). But there aren't enough users that there would be a lot of programmers willing to contribute.
If I open-sourced them, I'd be in the same position as Google with Android - funding the majority of it but having Chinese search companies replacing all my services with their own and selling it while simultaneously cutting off part of the revenue stream I use to fund further development.
I like open source, I use it, I contribute to it, but I have absolutely no desire to follow the Stallman "everything must be open source!" philosophy. I'm interested to hear other dev's thoughts on this stuff...
Re:Software packages, too (Score:5, Informative)
Different tools for different goals.
When you need to recreate the functionality of an existing application in a new application, as would be the case if you wanted to create a Facebook competitor, you may want the source code of the existing application.
When you want to integrate your new application with one that already exists, as would be the case if you are creating a complementary or dependent project, you want SDKs/APIs.
Developers do frequently use the APIs published for toolkits (jQuery, for example) and often load those toolkits from a third-party hosting service (like Google's, for example). This does create a dependency that would need to be updated if the hosting service made an incompatible change or discontinued their service, and that is something that developers need to keep in mind.
When developers tie into the APIs of platforms like Facebook and Twitter, it would usually do them no good to have access to the source code, as they are usually trying to tie into those existing platforms to connect with their user bases. If the developer chooses to make their application dependent upon a third-party API, that is a strategic decision and the committment is theirs to make. It makes sense if the purpose of the application is dependent upon the third-party platform.
As for published APIs interfering with open source development, I think it is possible that developers may choose to use proprietary products with published APIs rather than implement an open source solution. An example might be a developer choosing to use Google Charts rather than integrating gnuplot into their project. This might have some impact on the momentum of some open source projects, but the examples given in the summary are way off. A developer choosing to use an API published by Facebook for Facebook integration is not taking anything away from open source software.
Re:open source is a race to the bottom (Score:4, Insightful)
Yes! So instead of a single vendor holding its customers hostage, you get competition that drives down prices and a platform that is independent of the hardware.
That's a good thing. Well, unless you're a monopolistic corporation/control freak.
Re: (Score:2)
Because the software is running on your server, you are not distributing it, therefore you can even derive your product from GPL licensed code, provide an API, and never have to distribute your source.
Writing your application on top of that means that you relinquish your software freedoms ; you are dependant on an implementation you cannot elect to control for yourself. Which is fine, as long as you are happy with that risk. Most people already do this on their own hardware, so it's not much of a stretch. A
MOD PARENT UP (Score:2)
I thought the exact same thing. How do open APIs on facebook replace Linux as an OS?