What will the software solutions of tomorrow look like? They will be forged by four powerful elements: The Internet, Open Source, Mobile Devices and Web 2.0. We can debate the merits of each, but taken as a whole they will shape the genetic blueprint for the successful applications of tomorrow -- starting now.
Evolution and Global Warming have been my themes lately, but today we'll explore what these macro events foretell: mutation. The leviathans of our primordial software world have been busy hatching their vision for the next generation of solutions. But while size and scale have been advantageous up to now, four major events have set off an irreversible chain of events - altering the desired characteristics of software. In this new environment, nimbleness will again be rewarded and size may just be a disadvantage. Indeed, the meek have just gotten another crack at inheriting the earth.
The Internet was a meteor strike unleashing a myriad of possibilities; Open Source was a breath of fresh air; Mobile Devices began a great migration from the desktop and Web 2.0 brought everything to a more human level. We can debate the merits of each -- the Internet was a cataclysmic event, whereas Web 2.0 seems more like a change in the weather -- but taken as a whole they will shape the genetic blueprint for the successful applications of tomorrow, starting now.
How far have we come incorporating the internet into our daily lives? Where once relatives would ask me - being the 'computer guy' - how to format their Microsoft Word document, now they are purchasing their new computers online from the company store and plugging them into their broadband connections. My once promising career in family support is officially in the dustbin.
Everyone knows the virtues of the internet and, at this point, can even harmonize its praises. Combined with those aforementioned broadband connections, the internet has reached the point where its ubiquitous, dependable and - most importantly - taken for granted. It took years for a robust electrical grid to hook up all our houses. A few more for the novelty of flipping a light switch to wear off. Finally, once electricity from the wall could be counted on, we began to get cool things like radios and tvs. Ultimately the indispensable items like refrigerators, vacuum cleaners and washing machines - the stuff of everyday life - started showing up.
The internet grid is up, web sites have long passed the novelty phase and we've got our iTunes and YouTube. Now its time for the indispensable stuff. We'll have to wait a little longer to see what an internet-enabled vacuum cleaner looks like, or even what form it takes, but we do know how it will get there - online.
Save a Tree, Buy Online
Other than the massive MSDN software package that is trollied into our office every quarter, I cannot remember the last time I bought software in a box. Similarly, now that I've had my iPod for a while, my CDs are getting dusty and the last place I bought one is out of business. And guess what - my company makes software products and we don't even bother with packaging. At least not any packaging that needs trees.
It's all gone online. If the internet went down tomorrow and stayed down for a month, or long enough that people thought physical media was important again, we would very likely be out of business. Losing the internet probably wouldn't be very good for Read/WriteWeb either. In fact, all that our collective competitors have to do is take down the net!
The point is, it used to be only web applications betting their business existence on the internet. However, now it carries only a bit more risk than betting your company on electricity. Entities that used to either rely on physical media (publications and software houses) or combined the real and online worlds, are making the leap to be purely online. It can be a difficult leap to make if you're a newspaper looking at multi million dollar printing press investments. But if you blog, write software, transcribe medical dictation, produce music or direct movies, then you only need one thing to deliver your product: a large pipe.
Ubiquity, reliability and accessibility. Now we need a philosophy.
The first things that come to mind when mentioning Open Source is Linux, code in the public domain and young idealists. A grassroots competitor to the world's dominant software company is irresistible; stripping preternatural algorithms from the cloak of intellectual property is daring; and who doesn't like a young idealist? But for all the good Open Source philosophy has done, it hasn't accomplished what should be its true calling. Indeed, whereas a young curmudgeon has no heart, an old idealist has no head. Providing a legal means to open source code was nice, but it's more important to apply Open Source principles to data.
In fact, I would go so far as to say (if given a choice) that I would rather data be open and accessible -- than code. Code can, and often should, be rewritten and refactored again and again, but systems only work if they agree on the data. As we, and our computing devices, become more and more intertwined, it will become less and less important whether code reading my calendar appointments is proprietary or open; served by Microsoft's or Apache's internet servers, shown on a .NET or X.org display. What will matter is my calendar data adhering to (for example) the iCalendar format. As the importance of data becomes clearer, the origin of software applications, proprietary versus Open Source, will diminish.
It's All About the Data
Jeff Atwood recently accused Joel Spolsky of jumping the shark. While there may have been something fishy in that post, the fact is that Joel has written more than his fair share of brilliant essays - including one in particular that has always resonated with me, explaining how Excel reading and writing Lotus 123 data turned out to be the tipping point for success.
The immediate goal was removing the barriers for an application to win market share from a competitor. But the real lesson is even greater: if any spreadsheet application can read and write with any other spreadsheet application, then they can be evaluated on how well they work instead of how large their ecosystem is. Instead of resting on the laurels of one's barriers, companies will have to continually improve their products. You can choose what you eat, where you shop and what car you drive. Shouldn't we demand the same flexibility for our spreadsheets, appointments and online presence? Heck, the software code you buy isn't even yours - it's on extended loan. But your data is yours; created, edited and archived by you.
To Market, To Market
Open Source has captured the attention and time of many talented programmers; and as a result has shown the world what can be done. But what the Open Source movement needs is the attention and time of many talented marketers to explain why it's important. In typical engineer fashion, marketing has been the afterthought. But if the same effort in writing operating systems were put into marketing data standards, the idealists would be a step closer to their better world.
Honestly, though, the starry-eyed Open Source non-business model is just about a thing of the past. The most prominent Open Source projects today - Linux, Apache and Mozilla - have some extremely deep pockets behind them (IBM and Google). Do you think it's an accident that Firefox has been marketed so well? Something a bit more tangible than a dream is needed to incent the backers watching the bottom line. What's needed is a new catalyst.
Sales of mobile devices rocketing past sales of personal computers goes a long way towards capturing peoples attention. What are the ramifications of this? Whereas a personal computer was designed to be a generic device driven by complex software, allowing it to do most anything adequately, mobile devices are designed to run simpler software - combined with a more targeted form factor, allowing it to do a few things very well.
Today's desktop computers, and even laptop computers, have more in common with steriod laden athletes than trim computing devices. The new computer my aforementioned relative just bought came with 250 Gigabytes of disk space. It's going to take a lot of pictures of the kids to fill that up. In fact, if we average 100 100K pictures per week, the kids will be 480 before grandma's hard drive is full.
Mobile devices don't have it quite so good. They have to undergo rigorous testing in order to be light enough to carry, small enough to fit in your pocket and slim enough to be chic. Sure, single purpose mobile devices like the iPod can have large drives too - but programmers want wireless internet connectivity, more gadgets and widgets, and a development platform. The result is something akin to the early days of desktop computing, when the most memory anyone would ever need was 640K. Mobile devices don't work well with most data on desktop and laptop computers, simply because the amount of data is too large.
What mobile devices should do is work only with the amount of data they need to. Or to put it another way, you shouldn't need an entire dataset in order to be 'correct.' As long as you have a unique identifier, any other part should do. This will not only allow data to be more mobile, but will also make it easier to refine and specialize data interaction.
Wake Up and Smell the Data
Going back to the iCalendar example, we can imagine a circular mobile device supporting WiMax with two bells at the top that tells time - we'll call it iAlarmClock. While the completeness of the iCalendar specification makes it useful for just about any time based event, with the iAlarmClock we only have one pressing concern: when should the alarm go off? A proper, well formatted iCalendar entry may contain enough information to fill four pages of UML. Our iAlarmClock just needs the information from page four - Alarm Component Properties. Better yet, if I use the manual override - the roundy knob on the back - to adjust the alarm time, then the source iCalendar entry, and any other device depending on that source, should be updated automagically from my data fragment. That way all my iAlarmClocks will let me sleep-in, no matter where I take my nap.
We programmers have to get used to working with pieces of data instead of the whole thing. Sometimes it's ok not to have the complete picture, we just need that part that makes sense for the task at hand. The goal isn't data completeness, it's data usefulness - just enough to enable boring stuff like alarm clocks, refrigerators, vacuum cleaners and washing machines.
Go to Part 2 to read about Web 2.0, Social Glue, and The Missing Link!