Myth #1: Software should be free.
In the 1980s, I discovered structured computer databases. I loved the way they allowed people to organize things. For instance, it made it possible for organizations to combine mailing lists by merging the fields that contained specific bits of information -- name, address, and so on.
Nowadays, it sometimes seems like the only folks really getting their money's worth out of combining structured data are the spammers -- those sending unwanted emails to the rest of us. For many of the rest of us, sharing data is way too complicated, or impossible. All too often, the medium we use for sharing data -- sending email messages -- gets in our way, both because of the spam clogging our mailboxes, and because the structured data comes in hard-to-merge text messages, or in attachments which we can't always open or use. It's a problem that still afflicts organizations from the smallest to the largest. Even if an organization dictates that all names, addresses and other contact info be stored in one way only, folks keep finding new things to store that info on, new ways to gather that info, and the number of different ways data is stored seems to grow every year.
At a time when everyone talks about the freedom to do this or that with their digital data, not enough attention gets paid to what make it difficult to extract value from that freedom. What makes it hard to share.
The digital decade, now seven years old, was all about the promise of having your data anywhere you want, but also about being able to share it however you want. I believe that the current debate over freedom obscures how continuing competition between platforms -- those programmable systems that let us exercise our freedom to do what we want with our data -- ignores the larger comedy and tragedy of how hard it is to connect those platforms together.
It's as if we've been building not one electrical grid, but twenty. As if we've been building not one water supply, but six (at least one dedicated to hot water, and one to cold, and then other temperatures in between). As if we've decided that one phone network was the wrong idea, so let's build ten instead.
In the 1990s, I discovered the wonders behind digital networks, and it was good. The TCP/IP protocol beat all previous pretenders to be the single important network protocol, and the Internet and the World Wide Web flourished on top of it. It was as if instead of just a common electrical grid, we now had a common data messaging grid. (And it was even better than electricity, since electrical systems around the world vary, but TCP/IP doesn't.)
It turned out to be very hard to to try to build a common data-sharing infrastructure on top of the Internet. Much progress has been made, which I'll address near the end of this book. But those multiple platforms I mention -- the operating systems, programming languages, databases, Web page languages, and on and on -- they all complicate the sharing process. They nearly sabotage it at times. They add cost and complexity and sap value out of technology investments.
To try to cope, the computing industry turned first to traditional standards-making techniques, as practiced since the industrial age began with the standardization of rail gauges. But standardizing a rail gauge was a lot simpler than standardizing the way data gets stored on a digital device. Too many people have too many legitimate reasons to want to tweak that data storage to make one particular solution run a little better.
Then, the private companies who came to dominate the market for building digital solutions took control of the committees building the standards, and after that it wasn't always even about tweaking the data storage to make the best solution for that problem. Sometimes it turned into building something that made that company's entire product and service offering look better than a competitor's. Standards-making became another form of competition.
That's still pretty much where we are today in the digital decade. Standards get made by platform vendors who usually aren't interested in building common infrastructure, unless it puts their commercial rivals at a permanent disadvantage.
Software freedom is very often a good thing. Even a great thing, one that can solve many problems.
Not everyone agrees on what software freedom means. I'll return to that topic later.
But people still need to share structured data. Surely a world full of bright innovators could do something to bridge the gap. But what?
How could all software being free possibly be the answer? Hasn't the idea of free software been around long enough that if people really needed to share their data, enough free software would have been written to achieve that?
Free software advocates have overpromised and underdelivered the benefits of free software. Free software may encourage the adoption of free file formats -- those ways of organizing mailing list data, for example -- but free software cannot compel those who use it to agree on common file formats. It may just lower the cost of building the Tower of Babel.
Maybe it's not as simple as just writing enough free software.
