I’ve been fiddling around with Mountain Lion since a day or two after it landed. Every new release of anything provokes some anxiety among people who were used to the previous version, and Mountain Lion has not been exempt from that.
What’s driving the anxiety for a lot of people this time around is how Apple’s vision for user experience on a Mac is converging with its vision for UX on an iPad or iPhone, the ways in which Apple is deciding things in favor of “the average user,” and whether or not the next iteration of OS X will push things even further along a path that eventually involves people having to jailbreak their MacBooks to get any real work done.
I don’t think we’re quite there yet, and I’ve been pretty pleased with how well Mountain Lion has been running on both my 2009 iMac and 2010 MacBook Air. That doesn’t mean I’m comfortable with everything I’ve seen, and it means it’s time to start making sure I know how to get off a platform that may make changes I can’t accept when it comes time to decide whether to re-up.
I had a chat with my boss about this last week. As I was talking about the things iCloud makes pretty convenient: Automatically synced Safari reading list and tabs, synced notes, synced documents between iPad and Mac, he argued that there has to come a point where you don’t really want to cede too much to Apple to make “just work,” because you could eventually lose control of the things you care about most based on Apple’s whims. I think a lot of people have hit that in the past: You get to love some feature, a new release comes out, everyone insists there are no barriers to upgrading right now, and then you discover that nobody telling you to come on in because the water was fine cared about that one feature you loved that is now gone, maybe taking the data you kept in it with it.
That’s why I haven’t really allowed iCloud to get at anything I can’t easily export into a more open format. To Apple’s credit, there are a number of things that are easily converted into something useful by other software. Calendars, addresses and bookmarks can all be exported from a user-accessible menu. The new Notes app doesn’t have an export option, but it’s got a scripting dictionary. The new Reminders app is similarly provisioned. iWork allows users to quickly export any of its files to their Microsoft Office analog format.
At the same time, Apple’s new sandboxing rules, and the way it is restricting what can be sold through its Mac App Store (MAS) suggests that things could get dicey for apps more complex than a notepad or reminder list. Developers who depend on a freer run of the computer than Apple is willing to grant can always just sell outside the MAS, but they’ll be competing against products that might be willing to trade away some functionality to stay in the MAS. What’s good enough for the bulk of MAS users may not be good enough for me, and that gap will widen as we bring in apps that address more sophisticated functionality. That will have to place some pressure on developers. We don’t know what that’s going to mean, but that’s enough uncertainty for me to be thinking about what might have to be next. Which gets us to the point of this post:
I’ve started working on an outline that sketches out the issues I see involved in moving from a closed system (like a Mac, but it could easily be Windows) to a more open one (like Linux). This isn’t a new set of considerations for me: Keeping my data portable, or in apps where it can be easily exported, is something that has always been important to me, but I want to start thinking about more practically about how to make the move to a more open system in a way that doesn’t hamper my ability to keep getting work done all through the process, and that doesn’t force me to renounce the wonderful utility I get out of my current Mac software. So, the outline defines some terms and provides a place to think about the issues and also serves as a very practical inventory for the software I’m using, what its analogs are in the world of free or open source software, and whether those analogs are good enough yet.
It’s also a work in progress. I started work on it in OmniOutliner (which is excellent), but in an early effort to test OmniOutliner’s own export to more open formats I learned that its export/import capabilities are a little limited (maybe due to gaps in the OPML spec, maybe due to an oversight). I also didn’t want to pay $20 for an iOS version when document syncing still isn’t there and I’m not sure what my upgrade costs would be to get that syncing when OmniOutliner 4 comes out. So I decided to move the outline to Emacs’ org-mode, which uses flat text files and, as I’ve already been half-sorry to discover, has an iOS app.
I could have copied and pasted the plain text export of OmniOutliner into an Emacs buffer and reindented it, but it was easier to write a few lines of Ruby:
It doesn’t, obviously, do anything besides tack some asterisks on to the front of each topic row and drop in a row note if it exists, but it saved me some fiddling around.