Stephen O’Grady suggests that Google providing their own package repository may herald a future of ISV-managed repositories as part of a trend of distributing the power of the distribution maintainers. I hope not.
The problem with the strategy of providing your own repository is that you’ve lost one of the biggest advantages of a package management system.
The three main benefits of a package management system are, in short, (a) ease of discovery, (b) ease of installation, and (c) ease of maintenance. Given that quite a few applications (on every OS) come with automatic update mechanisms (e.g. “check for updates on startup”), item (b) isn’t a hugely differentiating factor. Item (a) really only exists because everything is already there when you install the OS. You don’t have to find the ISV’s website to download anything, since the package management system already knows how to find it (e.g. just type in “Ruby”)… which is not at all the case with ISV-managed repositories. That leaves you with ease of installation, and I do not think the process of setting up Google’s repository in, for example, Ubuntu qualifies as “magic.” If users start getting lots of their software from Google’s repository (perhaps even software only hosted, but not developed, by Google), then the one-time installation cost is fine. But that takes you right back to centrally-managed repositories vs. ISV-managed ones.
No, I think what Google has done here is a very practical avoidance of writing their own automatic update routines into every piece of software they write. It makes good sense, but I don’t think a proliferation of ISV-managed package repositories represents an appealing future of supposedly easy software discovery, installation, and maintenance.
Anthony Google, Linux
When I read the WWDC 2007 coverage (or here, or a dozen other places), what I heard was the first real cry for offline web apps. On desktops and notebooks, web-based apps are trying to displace desktop apps that don’t generally have an offline “problem,” but Apple has, at this point, forced the issue by creating a popular (?!?!) platform with no desktop apps to displace.
This completely changes the value proposition of offline-enabling technologies like Google Gears. If the iPhone is to be used as any sort of general computing device (not just a phone, and not just an iPod), and all 3rd party applications are to run in the browser, then it is absolutely necessary that there be some offline capability for web-based applications. There simply is no option.
This new-found dependence on Safari is consistent with the just-released Safari 3 Beta for Windows XP, Vista, and OS X, and a deep reliance on Google technologies is consistent with the built-in Google Maps for the iPhone that seems to be demonstrated every time an iPhone is turned on. So, the big question, where is Google Gears for Safari?
Anthony Apple, Google, iPhone
I think Dare’s hit on a big question mark surrounding technologies like Google Gears: branch and merge. I’m sure that any programmer who’s used source control and thought about how it all works has come up with situations in which an automated merge just isn’t possible (e.g. two people edit the same line of source). In the server replication arena, the same thing happens if you have backup servers that fail a lot. With one failure, you can switch to a backup, and then playback the changes to the first system when it comes online again (or even do a full re-sync). But if the backup goes down, then the primary comes online, you’ve got issues. The first server will potentially present the user with a state that is inconsistent with changes the user has made. This is the same scenario that will be encountered by users interacting with web services in offline mode. Make no mistake: this is not a solved problem. There are always going to be scenarios that will reveal the fact that offline != online.
That said, I don’t think too many software developers using a one-user source code repository have any problem mentally recognizing the need for offline changes to be synced before they will be available from the server. It’s a valid question whether or not that understanding will be found in people using Google Docs in offline mode, and I think it’s also the case that, a deeper understanding of the situation notwithstanding, developers have an easier time of merging thanks to a usage pattern based on having many discrete files that can be edited independently (that is, merging the text is less of a problem even if dependencies can break the program). But my opinion is that it won’t be that big of a deal. Most users won’t be editing documents on multiple devices with any great frequency, so there’s less of a chance of stumbling into an inconsistent state. Moreover, despite specifically targeting the disconnected state of modern devices, I don’t think the people providing offline enabling technologies are arguing that that state will be anything other than a transient disturbance (e.g. going through a tunnel, cable’s out for an hour, etc.). In that case, the most critical question when evaluating the potential for trouble relates to a specific usage pattern: how likely is it that the first device a user connects to an online service after a period of involuntary disconnectedness is the same as the last device the user connected with? I’d say it’s pretty likely, and, in that case, manual merges won’t become a significant part of software usage for the masses.
Anthony Google, Software, Technology
