For all of the technology industry’s historical focus on collaboration tooling, the vision of collaboration they espoused was typically narrow. When vendors talked about collaborating, what they meant was collaborating within your organization. The idea of working with those outside the corporate firewall was an afterthought, when it was thought about at all. Scheduling and calendar applications are perhaps the best evidence of this. Some 22 years after the introduction of Microsoft Exchange and nine after the release of Google Calendar, the simple act of scheduling a meeting with someone who doesn’t work directly with you remains a cache invalidation-level problem.
While this is baffling on the one hand, because it does seem like a solvable problem from an engineering perspective, it is at the same time unsurprising. The tools we get are the tools we demand, eventually. For the better part of the history of the technology industry, infrastructure software development involved very little collaboration. Instead, the creation of everything from databases to application or web servers to operating systems was outsourced by enterprises to third parties such as HP, IBM, Microsoft or Oracle. These suppliers built from within and sold to buyers unable or unwilling to create the software internally, and the closed nature of this system demanded very little low level collaboration between the individual suppliers, buyers or both. Buyer or seller, organizations were inwardly focused.
With the rise of the internet, however, came not just new opportunities but an entirely new class of problems. Problems that, in many cases, the existing technology suppliers were ill equipped to solve, because scaling an individual bank’s transactions is less difficult than, say, scaling the world’s largest online retail site in the weeks leading up to Christmas. Forced by need and by economics to develop their own software infrastructure, internet pioneers like Amazon, Facebook, Google, LinkedIn and Twitter evolved not only different software, but distinct attitudes towards its value.
These have been discussed at length in this space in the past. What’s interesting is that in comments like the one below, or projects like WebScaleSQL, we can see the possibility of a shift towards greater inter-organizational collaboration.
in all seriousness… Google, Facebook, Twitter and more should work together on just one of these monorepo focused build tools
— Chris Aniszczyk (@cra) March 24, 2015
The industry has had large collaboratively developed projects for some time, of course: Linux is the most obvious example. But to a large extent, projects such as Linux or more recently Cloud Foundry and OpenStack have been the exception that proved the rule. They were notable outliers of cross-organizational projects in a sea of proprietary, single entity initiatives. For commercial software organizations, Linux was a commodity or standard, and the higher margin revenue opportunities lay above that commonly-held, owned-by-no-one substrate. In other words, software vendors were and are content to collaborate on one project if it meant they could introduce multiple proprietary products to run on top of the open source base.
What if a higher and higher percentage of the infrastructure software portfolio was developed by organizations with no commercial ambitions for the software, however? What if a growing portion of the projects used to build modern infrastructure came instead from Facebook, Netflix or Twitter, who behaved as if software was non-differentiating and saw more benefit than cost to sharing it as open source software?
In theory, that would remove one of the more important barriers to inter-organizational collaboration. If Facebook intended to sell PrestoDB as a commercial product, or Google Bazel, it would be natural for them to protect those assets and shun opportunities to collaborate with would be competitors. But given that the software being produced by Facebook, Google, Twitter and so on is not built for sale, it would be logical for these organizations to centrally collaborate on common problem areas – just as they do with Linux, just as they do with WebScaleSQL, and just as they do with the Open Compute Project. Logic isn’t enough by itself to overcome NIH, of course, but collectively distributing the burden of scalable infrastructure promises enough financial benefit that the economic incentives should eventually win out. Particularly if people such as Chris Aniszczyk or James Pearce have anything to say about it.
We could, in short, be looking at the emergence of a new attitude towards software development.
- 1960: IBM: “Software is For Selling Hardware”
- 1981: Microsoft: “Software is For Making Money”
- 1994: Amazon: “Software is Used for Services That Make Money and Worth Protecting”
- 2004: Facebook: “Software is Used for Services That Make Money and Not Worth Protecting”
To which we might now add:
- 2015: TBD: “If We’re A) All Building Similar Software, and B) It’s Not Competitively Differentiating, Why Are We Not Building it Together?”
The best part? If organizations finally decide to collaborate at scale across company boundaries, maybe, at long last, the end of our scheduling nightmare will come into view.
