On Closed Systems And Open Systems

I just got done reading the Steve Jobs bio, a huge theme of which was this battle during Jobs’s life of open systems vs. closed systems.  Let me promise you, this is not going to be a post about which one is better, but I do hope that I can cast a bit of light on the perspective I’ve gained on closed systems.  My goal here is that reading this will help you understand that making a system closed doesn’t automatically make it worse.

There are some open systems that are doing incredible things.  An example of an open system that I use daily is Ruby on Rails.  The Ruby on Rails framework itself is open-source (which defines what I am licensed to do with the software itself) and it is also quite open, in that I am able to extend its functionality quite readily because it’s designed to be very extensible.  Ruby on Rails benefits greatly from being an open system because it’s got an active community of very good developers, issues get solved quickly, the system keeps getting made better, and I am able to do what I need to do with Ruby on Rails as a result of its openness.  If Ruby on Rails were a closed system and my ability to extend its functionality was not there or extremely limited, it would materially make RoR a lot less useful to me and less valuable overall.

At the other end, let’s look at a relatively closed system, iOS.  iOS is by far my favorite mobile operating system, but I’m limited in how I can use it.  I can use any web app I like on iOS, but if I want to use a native app with it, it has to come from Apple’s app store.  These apps are limited in what they can do and they generally live in their own sandbox.  I can connect to email services directly on the phone, and I can even link the phone directly up to my Twitter account, but iOS doesn’t provide a systemwide way to link up your phone to Facebook like it does for Twitter, and because iOS is closed, there are no hooks allowing you to do this.  However, iOS is very successful and I like it a lot because it is a great product and although it is closed, the team that built it thought carefully about the things I realistically would want to do with iOS and I can do these things with relative ease, and the iOS team put painstaking effort into making even tiny details right.  Instead of having to manipulate a scroll bar on the device, I can use my finger to swipe to scroll through lists.  Not only that, but the scrolling feels incredibly natural, and the software is so responsive that the list I’m manipulating with my finger moves in real time, as if my finger is manipulating a real thing.

Merely being a closed system didn’t make iOS awesome; there’s a slew of factors that go into that.  But being closed has its advantages (which I’ll revisit shortly).  There are, however, plenty of systems that are closed and are overall bad for customers.

Case in point: In the early 2000s, Sony had these awful music player devices. They would only sync with proprietary Sony software (which was allegedly not that great) and furthermore, they would only play music of a certain proprietary Sony format. Music companies in the late 90s and early 2000s came out with all sorts of closed systems in an effort to try to get consumers to not pirate music. They were poorly done, ran using only clunky programs and pretty much all of them ended up shuttering.

But the benefits of a closed system begin to manifest themselves when it comes time to evolve the system.  If you leave no customization options for your closed system available whatsoever, making a new and improved version of that program is dead simple.  But if you start letting parts of that system be extensible or customizable, for each piece you make open, that’s an extra burden of complexity for you when you want to improve it.  Take Microsoft Office, for instance.  In addition to being a behemoth of a suite of apps in its own right, each of the Microsoft Office apps have a full blown API available for them that allows developers to write macros and scripts that interact with the program, and it’s also possible to write add-ons that can let you change some of the existing components of the program itself (like adding a toolbar item or a contextual menu item, for instance).  If Microsoft wants to make sweeping changes to how you edit, say, an e-mail message, it has to make sure it does so in a way that doesn’t break any of its ability to be extended, and preferably do so in a way that lets previously written add-ins and macros continue to work without being changed.  That’s a lot of hard work!

Apple has this issue to some extent with its iOS APIs for making apps, but it’s not as complicated because none of iOS’s apps can actually be extended.  Furthermore, Apple is very adamant about requiring developers to use Apple’s standard APIs to do things.  For instance, when iOS 2 first came out, there were no push notifications. This meant that third party apps couldn’t notify you of things that were happening unless they were running.  While it would theoretically be possible for a developer to make an app that hacked iOS enough to allow notifications to get displayed when the app wasn’t running, Apple wouldn’t have allowed such an app.  When iOS 3 came out, push notifications became an available feature for iOS apps, and developers started using them.  There’s only one way to use these notifications, Apple’s way, which was admittedly inflexible, but it has a distinct advantage: when Apple made iOS 5, they completely rewrote how notifications get displayed to the user.  Instead of being modal pop-ups that annoyed the hell out of you when you were watching movies, they are now displayed at the top of your screen and get collected on your lock screen if you’re away from your iPhone and get a lot of notifications.  Had Apple let any old developer implement notifications any old way they wanted, this transition would have been a mess.  But by making the system closed and by only letting developers use notifications in one way, this transition required no change whatsoever to existing apps that used push notifications.  Once you upgraded to iOS 5, the notifications just started displaying in the new way instead of the old way.  It doesn’t stop there, either.  Since there is only one way of getting music into the iPhone’s native music library and only one method third party apps could use to access this music, it was absolutely no problem when iTunes Match became a feature of iPhone.  Third party apps that accessed iPhone’s music library would continue to work just as they always had, and they could still access tracks that were up in the cloud but not yet downloaded.  The app could see these because there is only one music picker control you can use: Apple’s official one.

Being an open system or a closed system can enable you to do things you otherwise couldn’t do with the opposite approach. It’s not something to get into a holy war over.

Leave a Reply

Your email address will not be published. Required fields are marked *

*