There's a dark side to these tightly integrated stacks of code: the walled garden.
The Internet began with the premise that there would be no gatekeepers. Every packet would be delivered to its destination, with our data free to wander. Alas, that promise is eroding, and not because the ISPs are increasingly turning to traffic shaping or deep packet inspection technologies.
These days, everyone seems to be retreating to walled gardens, where everything is safer and simpler. If you want to develop for the iPhone, you'll have to write code to Apple's vague specifications, then Apple -- and Apple alone -- will decide whether it will run on its machines. It's not up to you, the programmer, and it doesn't matter what the users say, either.
It's not just Apple. Creating games for Facebook means getting Facebook's permission to connect to Facebook users. It doesn't matter how many people click the Like button if Facebook decides to lock out your code. Microsoft, suddenly the most open and least restrictive of the big companies, is widely believed to be looking in awe at the success of these gardens and wondering why the Department of Justice treated Internet Explorer so differently. Only a naive programmer thinks that the other companies won't follow along.
There are deeper problems with walled gardens, beyond loss of control. Purveyors of walled gardens could very well keep the lion's share of the income derived from the work of independent developers. The revenues that trickle down to the programmers in the company town will be just enough to keep the server Ethernet lights flickering.
These walled gardens also threaten to balkanize the coding world into separate camps according to language. One look and you can see programmers moving from stubborn individualists in the open frontier to hired hands. Welcome to the new plantation.
For all the success of open source software, the ability to engage in pure tinkering is slipping away in many corners. The success of the iPhone has everyone looking to find ways to wall off the commons. Sure, the new car computer systems are built with Linux, but don't for a second think you'll be typing "make" and deploying to your car.
Even if we concede that it would be creepy and dangerous to reprogram your brake system, why can't we hack the nav system? The car companies are touting how their fancy computer systems integrate with your phone, but they're not open the way your desktop is open. Hardly anything is as open as the desktop used to be. Even desktop systems may be more locked down, with some wondering whether the new secure booting infrastructure for Windows 8 will make it impossible to run alternative OSes.
This is bound to limit innovation in the future. After the garage hackers and programmers finish building tools that put a smile on their faces, they turn around and create companies that do the same tasks for the average person. Slicing off the open source experiment in this area destroys the aftermarket. And it becomes harder for companies to hire the programmers they need because open source tinkering produces skilled programmers that can fill jobs.
There remain glittering exceptions, usually when the code is shared between programmers. Some projects like Apache still thrive and attract the kind of financial support they need to pay top talent. Github and Sourceforge continue to add more projects. Others work well for developers experimenting with the bleeding edge. But there are few examples of pure openness succeeding with the end consumer, who seems drawn to the siren call of proprietary gardens.