Over the past few years, cloud sync has become a "thing". Users are working on multiple platforms now more than ever and they want their data to seamlessly show up everywhere. As this demand first emerged, we naturally looked to companies dedicated to providing cloud synchronization to offer solutions. This led to the rise of Dropbox, Box.com, and other similar service providers. Shortly afterward, the big companies got involved and now Apple offers iCloud, Google offers a variety of synchronization services, and Microsoft is also in the game with SkyDrive. When this first started, I assumed that that would be the end of the discussion. Companies like Apple and Google would offer synchronization services for which software developers would plug in and we'd move on. The reason I was so willing to think synchronization stopped with companies like Apple and Google was because the servers and back-end required to make that happen were so expensive that small developers simply could not roll their own sync services. I'm no longer convinced that is the case.

Tying a key component of your software—such as synchronization—to somebody else's technology isn't a good idea if it can be avoided. For instance if a developer wants to use Apple's iCloud, she must sell her application through the App store. Even if there were no conditions tied to it, a developer is still relying upon the continued support from these large companies to keep their applications running. If it suddenly didn't make sense for Apple or Google to continue supporting synchronization or perhaps they made a small change that breaks syncing, the developer is screwed. Another problem with giving synchronization over to a different company is the loss of control. If a customer has a sync problem, there is a good chance the developer can do nothing about it. Tying to an app to iCloud also makes it difficult if you are selling on multiple platforms as well. iCloud doesn't support syncing to an android device.

For these reasons, app developers are looking to host their own synchronization services. This leads to what I would call the third phase of synchronization development. Specifically, app developer hosted synchronization. We are already seeing this happen. Earlier this year The Omni Group release its own synchronization service for its applications. I know that this was no small effort. The Omni Group spent years getting this right. Rovio has done the same with the popular Angry Birds franchise. The latest Dropbox initiative also seeks to provide a platform for developers to easily sync rudimentary bits of data for their applications. Wheels are now in motion.

While not all developers have the resources of companies like The Omni Group or Rovio, it is still early days. As people figure out this widget, it will get faster, easier, and cheaper to build. I suspect in the next two or three years, hosting and managing synchronize data will be a realistic option for small app developers. It makes a lot of sense for app developers to maintain control of this vital component of their software.

So what does that mean for us users? For one thing, we are no longer going to have all our data-eggs in one synchronization basket. The reliability of a synchronization mechanism will become a key component when evaluating software. A great app with a lousy sync won't make the cut. Another effect of this will be the overriding concern for security. Instead of giving all of our data to Google or Apple, we are going to have bits and pieces of it spread out between various companies. Users are going to have to make a decision as to whether or not they can trust the vendor with key data before giving it to them for their synchronization engines. I also hope this generates a bit of an encryption arms race between vendors, resulting in better cloud encryption for users. Most importantly, this allows developers to control the entire widget and should result in a better user experience.

We've witnessed a revolution in data sharing and syncing over the last five years. I think the next five should prove just as interesting.