What Makes Synchronization Difficult
Wednesday, February 7th 2007 | Ismael Ghalimi
Earlier today, I had dinner with my friend Francis Pisani, French compatriot and prolific blogger for famous newspapers such as Le Monde, El PaÃs, and Reforma. We discussed about a variety of subjects, including a couple that are dear to my heart: good food and Office 2.0. On the gastronomic side, we pretty much agreed on everything. The same cannot be said about Office 2.0, and we focused our discussion on the complex issue of whether or not synchronization is really needed for Office 2.0 to get mainstream adoption before our brains get directly wired to the Internet.
I am not a strong advocate of synchronization, for I believe that it is too complex to use, and that it is solving a problem that will essentially disappear when most of the population gets high connectivity access to the Internet. The development of broadband connections and mesh networks will take us there sooner or later, and the question becomes what to do until this happens.
But before we dive into the details of what makes synchronization a really difficult problem to solve, let me clarify something: I believe that synchronization is useful for a lot of applications and to a lot of people, and I am not trying to make a point against it. Instead, I am more interested by trying to understand whether the problem it is trying to solve could not be addressed in a completely different way, while delivering a better experience to the end user. That being said, let’s dive in.
Synchronization is difficult not because we’re not smart enough to develop technologies for it and market them appropriately, but because the mathematics that govern it are fundamentally complex. And I don’t care how good you are at marketing, for marketing cannot beat mathematics, no matter how hard you try. Trust me, I’ve tried.
Within a single user setup, synchronization turns out to be a manageable problem to solve, even when using multiple devices. One of the best synchronization tools I have ever used — and I must have tried most of them out there — is Apple’s iSync. It lets you synchronize as many devices as you want, including desktops, laptops, and mobile phones. Its conflict resolution algorithms are pretty straight, and if you make sure to synchronize your device before you make any changes to your records, you will never have to manually reconcile out-of-sync data. So far so good, and based on this success, most people think that synchronization is the answer to the need of being able to access your data when being offline. Problem is, the whole thing breaks when you move from a single user setup to a multi user environment.
Office 2.0 is all about collaboration, and collaboration is all about working with other people. When doing so, you have to share documents or objects with multiple users, who themselves are using multiple devices for contributing to the collective effort. Multiple people interacting with multiple copies of the same document at the same time means than multiple potentially valid modifications to the document are being made in parallel. When this happens, who will decide which one to take when time comes to synchronize everything? This is not an easy question to answer. It becomes even more difficult when there is a need to merge changes made by all contributors. At this point, things get really tricky.
If you need to convince yourself that such a problem is not an easy one to solve, just ask software developers about their use of a source control system such as CVS. For a long time, the only way to make it work was to use a central repository from which developers would check a bunch of code out, make modifications to it while being offline, then checking it back in. The source control system would merge all the changes, and assist developers in dealing with conflict resolution when more than one person would have made modifications to the same piece of code at the same time. In such an instance, conflict resolution would be done by manually comparing changes one class at a time, and in some cases one line at a time.
This is all nice and dandy if you are a software engineer, but most knowledge workers are not, and do not have the time to learn the details of such a complex architecture. Furthermore, documents developed with office productivity tools do not have the level of granularity that source code packaged through classes natively exhibits. It’s not easy to break a sentence or a paragraph into atomic pieces that could be put back together by a piece of relatively simple software.
Furthermore, source control systems work well when using a central repository, but as soon as you want multiple repositories to support the collaborative work of larger teams that are geographically distributed, things start to get really complex. This problem is not an impossible one to solve — WANdisco is solving it to a fair extent — but definitely not a trivial one, and one that requires the development of extremely complex algorithms, and the use of interfaces that are way beyond what any casual user would be willing to deal with on a daily basis. Remember, we’re taking about office productivity here…
This is where the problem lies: in a multi user environment, synchronization is an inherently complex problem to solve, and the cost of solving it from a user interface complexity standpoint does not warrant the investment. There, you essentially reach a point of diminishing return that should convince you that synchronization just isn’t the right way of approaching the problem.
So what’s the alternative? Well, it’s pretty simple actually: get connected! Get connected by any means possible, anytime you really need to get access to your data. And when you cannot, find something else to do. If you’re in a plane without connectivity, take advantage of this offline time to read a book, watch a movie, or take a well deserved nap. As soon as you land back on terra firma, you won’t have any excuses for indulging these anymore. And if you really need to work on this contract while you’re flying to meet a customer, by all means feel free to download a copy of ThinkFree Desktop and go crazy offline. But don’t bother to synchronize all your data before you do so, for you won’t need it anyway.
Now, when you look at the problem from a productivity standpoint, you will soon realize that the real issue is not one of connectivity, but one of mobility. Most of the office productivity applications we are using, be they from the first generation or the second, are designed to be used with a full size keyboard, a pointing device, and a large display, not the mobile devices we carry with us. And here is the catch: these mobile devices tend to be connected most of the time when we need them to be, but their form factor just isn’t good enough to let us get things done. To make a long story short: we’re connected most of the time, but when we are, we do not have the right device for the job. Therefore, I contend that the problem we have to solve is all about getting the right user interface for the right device. And do it while assuming that we are always connected when we need to.
Once you make this shift, you immediately understand why a device such as the iPhone is so critical for Office 2.0 alternatives to become truly pervasive. Because ithe iPhone features a full-fledged web browser that can natively display any web page and support AJAX user interfaces, it gives me reasonable hope that high connectivity and mobile accessibility to my Office 2.0 setup is litterally around the corner.
And while I’m waiting for June to come, I’ll continue the discussion with Francis.
Entry filed under: Office 2.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It’s hard (for me) to counter Ismael’s argument on the mathematics of synchronization. I have nothing to say against his affirmation that “Office 2.0 is all about collaboration.” My points—the ones I made during our conversation yesterday—are two fold.
First, there will be a longer time than most engineers tend to think between now and when everybody will be always on with a broadband connection. Ignoring that contributes to a reluctance in adopting the new possibilities.
Second, in a web 2.0 world, technology adoption tends to move from the edges to the center through people’s fancies. In other words, in w1, CIOs opened the way (more or less forcefully, more or less successfully), while in w2 people discover functionalities outside the corporation, adopt them, and then ask CIOs to implement them for their company.
Therefore, besides exploring what can be done in an extreme manner (what Ismael does in a wonderfully smart and thorough way), you have to find ways of bringing people in. No better way for that than to take into account their problems and habits, while opening a door to the new world.
That reminds me of the tension—not long ago—between web designers and users related to the size of their screens. Most of us have big screens now, but for years we had to suffer sites, projects, and pilots designed for screens that most of us could only dream of. The answer was adjustable width. Many web designers tended to despise it. That’s exactly what we need now.
We need tools that allow us to progressively get used to the depth of what it means to “use the web as a platform”. It would be nice to be able to synchronize what’s more personal, or the work documents that are still works in progress in our own minds. The best workers have a personal life which does not disappear when they step into their office. The most efficient employees need time to work on their own contribution to the collaboration process.
Taking this apparently immaterial reality into account might result in a much smoother, and speedier, adoption of web 2.0 as a platform, as a space of collaboration. The issue might be less about syncronization than about transition. The former is a technical issue, the later a human one.
It could prove significant if we agree that a key part of web 2.0 (and Office 2.0 for that matter) is about webonauts, the content they generate, the collective intelligence they produce, and the power they share.
I think you’re underestimating the propensity of engineers to choose simple tools that get the work done with minimum amount of effort.
We call it source control and versioning for a reason. We minimized the problem to text files. And text files are very simple to merge, not always easy—that depends on how complex the code you’re merging is—but definitely simple. It all boils down to lines. And after you merge those lines, you run the test cases.
What about non-technical people? Would they ever be able to “learn the details of such a complex architecture”? Well, Wikis took the exact same approach to versioning by diffing text lines. They use a slightly different approach to testing, called peer review. Either way, I heard Wikis are immensly successful even outside the developer elite.
To their merit, Wikis are simpler than source control. Because programming languages are so varied in their syntax rules, it is hard to recognize meaningful units, and best a diff tool can do is line by line comparison. In contrast, human languages in written form follow very simple rules, that make it easier to diff paragraphs, sentences and even individual words.
A Wiki does just that. It allows a client to download a shared resource into its own local copy, make any number of changes to that copy, and then submit those changes back to the server for merging into the shared resource. And apparently, it scales extermely well.
So synchronization is not the problem.
Keeping with the Wiki analogy, imagine these two options:
1. A $500 top of the line, high resolution PDA last synced 5 seconds ago. Except that it was synched with an Encylopedia Lite, covering limited subjects with summary articles, most of which were not updated in years.
2. A $50 cell phone with a web browser that can access Wikipedia.
You’re out of the office, some question pops up. Which of these two devices will let you kick ass, impress your friends, maybe close the deal, by finding an authoritative answer on the spot?
I argue that the device or service that can do that, will prevail.
The rest is just details.
Synchronization is a topic that is particularly important to me, so I was delighted to find a thoughtful article about it. I wish I had time this morning to write a more considered response, but I have a meeting about licensing a lot of seats of our synchronization software to a large institution. Apparently they’ve decided not to wait for ubiquitous connectivity… I promise to return to this thread though. I think it’s central to the development of Office 2.0.
Regards
-Charlie
The age old problem of synchronization comes back after 30 years, which is the half life of one economic cycle—60 years. Tandem solved the syncronization problem back in 70’s with two-phase commit in rational databases—the all or nothing strategy to keep every copy of a distributed database in sync.
The question is why does the synchronization problem comes back to haunt us again? It is because of the recycling of the asynchronous mode of operations. It began in the early 90’s when IBM promoted its Message Oriented Middleware (MOM) software. MOM was a way to even out the workload on the Mainframe throughout the day. With the loose coupling of components, the client component needs to provide a call-back capability for the server component to send results back.
In essence, everything is time based. The temporal dimension is the key to keeping things in proper sequence and order. There is no need for complex mathematics. Do we really need Topology, Category Theory, or Catastrophy Theory to solve the simple time dimension problem? A lot of research was were done in the are of temporal databases. Unfortunately, none of the research results was incorporated into commercial database software, with the exception of timestamp, which is good for audit and recovery purposes in the database log.
The real problem is that IT people keep on promulgating the myth that everything must be updated up-to-the-second. Except for real-time control processes or telephony applications, most transactions are settled on a monthly basis.
The way I see it is that many of us recycle problems, and never look at historical solutions! So, we need to reinvent the wheel every now and then. This is a good way to rehash the same old things with new names and packagings in the absence of real advances in solving problems. It won’t be long before an equivalent of DSS (Decision Support System) will surface in the market place based on AJAX and SOA, without providing real decision support capabilities, similarly to Office 2.0—a severely crippled Office 1.0!
Many good points (and counter-points) have been raised on the topic in this thread. So, at the risk of taking it a bit off-topic, I want to comment on Ismael’s points on mobility and device limitation.
I have been a firm believer that we have not fully utilized the convenience and productivity gains of audio and voice-enabled possibilities. We have seen the evolution of Web 1.0 from a mostly one-way rendering of visual text and graphics, to where we are today with Web 2.0 capabilities that allow for a bi-directional consumer/producer collaboration a la blogs, wikis, and content contribution in the form of not only text and images, but also videos and some loosely defined audio in the form of podcasts.
I think the next big move towards solving the device limitations, i.e. small screens and keyboards, is to launch into a more ubiquitous integration of our audio/verbal sensory capabilities directly into collaboration behavior and technologies. I’ve seen some examples of products and companies beginning to do this, but more is needed, and there will undoubtedly be opportunities for an innovative product to come to market.
Somehow related, a project about making Web 2.0 applications available offline. They are also facing the synchronization issue. The advantages of being able to work offline are big—even though I agree with Ismael, sooner or later, this won’t really be a question any more). Maybe some basic user education would be to modify offline only documents unlikely to be modified by someone else, or separate the changes from the main part of the document, and let the user do the merge herself later on.
Francis,
I agree with everything you said, especially with respect to collective intelligence.
Je vais mettre un peu d’eau dans mon vin…
Best regards
-Ismael
Assaf,
Good points about Wikis regarding versioning. I need to dig into this some more.
Best regards
-Ismael
Charlie,
I’m looking forward to your thoughts on the subject. And while we’re at it, I want to say that as much as I dislike synchronization, I am a huge fan of syndication, which I believe is solving part of the problem at hand in a much simpler way.
Best regards
-Ismael
Kooros,
I agree that voice recognition is a critical step toward better user/device interactions.
Best regards
-Ismael
Lucho,
Education is hard. I tend to prefer self-explanatory user interfaces.
Best regards
-Ismael
[…] Ismael suggests the issue of disconnected web access arises not because we need disconnected web apps, but because our productivity apps don’t translate well to mobile devices. (tags: disconnected-mode synchronizedweb mobile) […]
A warning for IT folks who push unrealistic solutions or vaporware. The article Bridging the CEO-CIO Gap is a reflection on IT people who push technologies without realizing tangible business benefits. I believe that all CIOs should be demoted in rank and report back to the CFOs again, as it was in the 50’s!
Synchronization is the future of Office 2.0 (or let’s call it Office 2.5)
As most Mac users have already understood, there are several reasons for this :
- Offline vs. online
- Useability of web GUIs
- Data model compatibility of different web services
- Simultaneous availability of multiple web services
Offline vs. Online
To use Office 2.0, you need to be online: trivial ! But there are several reasons why you may not be or want to be online: your Internet access is down just at the wrong moment, you know when you need to send that last minute order to a supplier/partner to kick-in before the cut-off, before the truck starts off on its delivery round.
Do you really want your business to rely on the uptime of your Internet access or, if you are a SO.HO, of your ISP/telephone provider? You might also just be in an airport, a taxi, or somewhere where you just do not want to send your order through unknown wires, but do have time to do you back-office preparation work.
Office 2.5 needs to work offline—except when not possible, of course, for example when you submit work to shared business processes implemented in your online workflow engine.
Useability of Web GUIs
Yeah, AJAX is cool, web application are getting really sexy, etc. But wait, remember your PC or Mac interface? Even the dullest of those is better han the latest AJAX frills: response time, multiwindowing, graphical guidelines, etc. When you have worked on a Mac, you know what productivity is about, and most of that is provided by a good man-machine interaction: drag and drop, fast dynamic menus, graphical interaction where needed, and, above all, consistency! Today, each Office 2.0 has different GUI guidelines—mind you, more and more Mac applications are stepping out of Apple’s own guidelines…
So, any local Mac application has a better GUI than the best Office 2.0 service.
Data Model Compatibility
Now, for those who use more than one online service, you may have noticed that their data models, for the same service offered, are slightly different: in this situation, the user needs to bridge the gap between them, e.g. Google Calendar and Salesforce.com Events, knowing that this type of information will be stored in one, and that other information will be stored in the other service. And I will not even mention compatibility issues, data model upgrades of one and not the other, etc. An integrator’s nightmare… managed by the end-user?
No, the data model integration and compatibility issues need to be managed by the synchronization applications that have been tested to work together and to pull all the online data back into my (Mac) synchronization engine, into the (Apple) standard, and (developers’) custom schemas—which, by the way, could be standardized by the Office 2.5 movement so that all these services stay compatible—which will also work offline (Cf. first point).
So I need synchronize applications to pull data back into my Mac to maintain data model compatibility.
Simultaneous Availability of Multiple Web Services
Last but not least, the multiple web services I use must all be available at the same time if I am working online, also at the same time as my Internet connection is on. So, in real life, my business is relying on the weakest link in the chain of web services and Internet connections I use. The more web services I use, e.g. to increase my Office 2.0 productivity or to improve my added value, the more I rely on weak links in the chain of my Internet business partners.
Now, I did not really think that this was a big deal, even after the important Salesforce.com Oracle upgrade problems, or others; but the fact is that all these services put together multiply the risk of having one of them unavailable at the wrong moment—Murphy’s law, remember?
So, I need to synchronize all that stuff off the net onto my local Mac to work while others are stuck fixing the bugs in their online services. Yeah, my productivity will decrease, but I will spurt all that work back into the service when it comes back online.
I hope you realize that Office 2.5 will be offline, with the power of local GUIs, the (Mac) synchronization engine providing the data model integration services tested by the suppliers of those synchronized applications, and that most of the work will be done offline, even if the Internet line or the Salesforce.com’s of this world are down.
-Rup
Quote: “This is where the problem lies: in a multi user environment, synchronization is an inherently complex problem to solve, and the cost of solving it from a user interface complexity standpoint does not warrant the investment.”
I’m afraid I do not agree with this. As you say higher up, the real difficulty is synchronizing multiple, remote servers, at different times, which are not necessarily online at the same time, etc. But hell, this has worked for Lotus Notes users for years, hasn’t it? I mean, please let’s not re-invent the wheel and create problems which have already been solved by previous generations of software architects.
Difficulties in synchronizing data are due to multiple updates to the same item; thus the great debate on lock+checkout (at the risk of someone never releasing the lock) or modify+sync+resolve conflicts. As usual, even in the days of CVS, conflicts may only be solved by a phone call (or email or IM chat), which is good for the way the company works; at last, a good reason to call another buddy on the other side of the planet and talk about real business, not just poor network/intranet performances or incorrect access rights.
Rup,
You raised many valid and excellent points on accessibility and synchronization.
Personally, I won’t hold my breath on my ISP’s reliability of access to the Internet. We have only two ISPs to choose from—Sympatico (part of Bell Canada) and Cable Company (one in each market). When it rains cats and dogs, both ISPs go down for hours, if not days.
Ismael has many gadgets to access the Internet; namely, Apple, iPhone, Blackberry, etc. He has land-line, wireless, and possibly satellite access with no single point of failure. It is unrealitic to expect everyone has a similar set of equipments like his!
Synchrozination consists of three fundamenal problems: 1) time, 2) content, and 3) schema (data compatibility as you call it). The web user interface (AJAX and SOA) addresses primarily the interaction between an individual user with the server (machine). It addresses neither collaboration nor multi-lingual operations. Moreover, the current Office 2.0 (or 2.5) and Web 2.0 miss the security dimension.
After the Year 2K millenium software upgrade, dot com bust followed. The second coming of dot com bust is already looming on the horizon. This time we will see how many open-source enterprises will survive! I’m quite sure that IBM, Microsoft, Oracle, and the like will survive, as they play in both the proprietary and open-source markets. I am quite sure that Apple will survive too, as Microsoft will not let it go under for any reason.
The Web 2.0 and Enterprise 2.0 movements seem to widen the gap of the digital divide. Motorola, Microsoft & McCaw invested heavily in LEOS (Low Elevation Orbital Sattelites) to promote remote access to the Internet for locations with very little or no infrastructures. Motorola’s LEOS were up and running for a couple of years, but never made any money. China and the European Union have teamed up to build another GPS sattelite network to offset the U.S. monopoly. With urban mesh wireless network, Internet over the electric transmission grid, LEOS, and GPS, no single point of failure in Internet access may become a reality economically!
Best regards
-Francis
[…] Tonight, I had dinner with Francis, his wife, and friends at their house Berkeley. We discussed about Office 2.0, good food, French politics, and the thrill of sailing around the world. Guillaume, one of the guests, did just that for a year with his wife and kids, and shared some very cool stories on his blog. I’m not sure May is up for it yet, but we shall see… […]
I hope it is never too late to learn French. I am a Canuck, supposed to know the other official language—French. I am bi-lingual, but in the wrong language though. The only French sentence that I know to survive in the business world is: “Parlez vous Anglais ?”, which I need when calling Ottawa. Nevertheless, I’ve architected multi-lingual software that has only one source code to run on IBM Mainframe, Wang, and PC. Hopefully, one day I can converse with Ismael in Parisian French, not Québécois or Acadian!
Hi,
I’m not trying to hammer it in, but maybe you should have a look at Firefox 3 rumors and Google Apps. They seem to be aiming for offline.
“Told you so !”
-Rup
Offline access to browser based applications makes perfect sense. Users like me who don’t have reliable access to Internet can now work with documents and collaborate with others without being online 24/7.
It looks like Microsoft and its competitors are converging to a similar user experience model—running applications inside a browser. Office 97 was the first office suite that could work within IE. Office 2007 can work both in workstation and SaaS modes. The equivalent of SaaS was introduced a long time ago when Microsoft talked about subscription service, kind of an ASP (Application Service Provider) model for Office Suite after it released Office 95. MSN Live is the first attempt by Microsoft to provide an Office subscription service. Microsoft did try to push the subscription service model to large corporations, including government agencies, but customers would not get on board with the subscription service for a variety of reasons. This is very similar to IBM’s push to retire MVS, but large customers refused to move off MVS as they had spent millions of dollars to remove the Y2K bug from software less than 10 years ago!
It looks like Office 3.0 will be a hybrid computing model of online and offline web services. The X-terminal equivalent (workstation with no disk) promoted by Oracle and Sun will be dead again! In the end, I believe that a compiled software (e.g. Office 2007) will beat interpreted software (Java based) in terms of performance on the same platform.
It was interesting to see that many cute acronymns cropped up, but they are just the same old practices wrapped in new packages. There are only two basic business models—a customer either buys or rents a product! It all depends on the economics of ownership.
Rup,
You’ve got a lot of good points, but I must disagree with your overall thesis. To me, the real issue of working offline is not getting access to data, but getting access to applications. Data is useless without supporting applications. And the more your applications rely on web services and foster collaboration, the less they becomes accessible offline. What would be an offline version of Google’s search engine? Something pretty useless. Have you tried the offline version of Salesforce.com? It’s utterly unusable as soon as you want access to custom objects.
Reality is, we’re moving to an online world, and trying to deal with offline considerations makes this move a lot more difficult than it needs to be. Granted, Lotus Notes has pretty good synchronization, but it only works for Lotus Notes users, not across an ecosystem of applications developed by multiple vendors. And standards won’t help there, for the issue has less to do with APIs, and more to do with core application design. The same is true for Mac OS X applications working with iSync: only the most trivial data sets are supported. As soon as you move toward more complex ones, the architecture breaks.
To me, connectivity will evolve the way that electricity did. Pretty soon, we will reach a tipping point when connectivity becomes a commodity, and we won’t look for alternatives. The real question is whether this point is five, ten, or twenty five years down the road. My vote goes for five. What’s yours?
Best regards
-Ismael
Francis,
I must disagree. Microsoft does not have a version of Microsoft Office that you can use online with any web browser, on any platform. If you’ve seen it working, please let me know where I can buy it, for I’d love to give it a try. Even though patterns repeat themselves, not everything remains the same, and each cycle in the pendulum’s oscillations brings its fair share of progress. The online version of ThinkFree is a lot better than any office productivity suite that was available in the early 90’s. It’s not yet on par with Microsoft Office 2007 in terms of features, but it has some that offline versions of Microsoft Office will never be able to provide, especially with respect to collaboration and mobility. To me, the trade-off goes in favor of online alternatives.
Best regards
-Ismael
Ismael,
I do agree that MS Office won’t work on any platform except Windows and Mac for now. In terms of collaboration, it has SharePoint. I believe that the web version of Office Suite will work on other client platforms when Microsoft’s underlying office document standard becomes one of the ISO standards, in addition to OpenDoc. To protect its server market, Microsoft would not support UNIX and the like. It could when it changes its mind. Xenix was Microsoft’s version of UNIX! Mac’s OS is practically a UNIX now. It won’t be too difficult for Microsoft to make MS Office to run on UNIX or its variant. Interesing enough, IBM’s AS/400 and Sun’s Workstation did have an optional emulation board to run MS Windows inside their machines! Linux desktop doesn’t seem to go anywhere. There were two versions of Window Manager in UNIX world - one was Motif and the other was OpenLook. With Mac, it has a third one. The underlying window API is still x-window, which was written mostly by DEC and donated to MIT as its owner. I did look into UNIX for clients back in late 80s and early 90s, but the software running on UNIX was too expensive. For instance, WordPerfect on UNIX was at least twice as expensive as a Windows version for a PC workstation. Moreover, an x-terminal (diskless workstation) was more expensive than a PC - double for a monochrome and 4 times for a colour one!
Office Suite does work within a browser - IE on the Windows PC. The Mac version may work too, but I am not sure, for I haven’t touched a Mac since 1987. It was too expensive to own a Mac at that time and it still is! If you want to have the Microsoft Office Suite working on an UNIX-like platform, it is not there yet. There was a company working on migrating .Net to other platforms, as part of it became an EMAC standard. Not like Java, Sun would not relinguish the control of it. Sun, in fact, withdrew its ISO accreditation for Java in the last minute. As far as I am concerned, Java is a proprietary environment and language in the computer world! Sun may let you do a lot of extensions, but it has the absolute right to stop any extensions as it did in one of the Embedded Java meetings. Sun told NIST that what it proposed was an infringement of Sun’s intellectual property. How arrogant a corporation can it be! It looks like that Sun has gone down the same path as IBM did back in the 60’s. I am waiting to see when Sun starts collecting patent fees from every vendor and user! It will be similar to MP4. Part of the cost in producing an MP4 file goes to its patent owner! In effect, every MP4 based song or video you play in your iPod, you have already paid for its patent fee, at least indirectly. Luckily, W3C would not accredit any patent fee collectible standard!
In terms of collaboration, Microsoft’s answer to IBM’s Lotus Note and Domino was IIS, Exchange, SharePoint, OneNote, and InfoPath. In answering to Netware, Microsoft moved to DNS based directory structure. Practically, no one talks about Netware these days! Even IBM’s Global Services has a dedicated group of certified MCSEs to serve its world-wide clients or customers. IBM was smart enough not jumping 100% into Java based open source. It is also a big player in the Microsoft’s Windows arena to make money.
In terms of open source movement, companies specialized on Windows platforms are starting to offer free software for download. Microsoft led the way by offering its software development environment in seperate packages for free! As more .Net open source software become available, I would use a compiled software instead of Java based software on my Windows machine. I can’t afford to buy a Mac and I hate to waste time to configure and support a Linux platform. Don’t forget, 90% of workstations are Windows, 9% are Mac, and the rest, whatever they are!
Best regards,
Francis
[…] ThinkFree Portable Edition is essentially a clone of Microsoft Office 2003, minus macros and pivot tables. It has the exact same features as ThinkFree Online Edition, but works offline, and lets you store documents on the USB drive or on your computer’s hard drive. Now, with all the chatter about synchronization we have had last week, you must be asking yourself why I am promoting an offline office productivity suite, aren’t you? Well, I might have opinions, but it does not make me right. And what works for me (being 100% online), might not work for you, and I am aware of this. […]
When one can afford to pay for any services available under the sun, online or offline is irrelevant. Offline can be turned into online asynchronously when a connection to the Internet is available! Synchronization of document is a solvable problem. A master author can always password protect a document, and let other contributors make revisions. S/he then incorporates relevant revisions into the final document. This mode of operation was in force since Internet was released to the public at large, and there was no web browser then. Telnet was the primary means to send and receive electronic documents. When there was no access to the Internet, documents were attached to be sent and received through computer-based Fax—a very expensive way to exchange documents over long distances in terms of cost. Collaboration half way across the world (Toronto to Singapore) was quite a challenge, even with access to the Internet. Time differentials were a real problem, and still are!
[…] I am not a strong advocate of synchronization… […]
As the web becomes increasingly interconnected and applications continue to blur the distinction between desktop and web, we should expect to see more applications that allow web/desktop synchronization. This will happen due to the increasing development of web services that enable applications to work equally well across web and desktop clients.
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment