Friday, October 26, 2007

Apple's Ruby: Communities, Not Features

Apple supports Ruby and Rails very enthusiastically, and Laurent Sansonetti makes an awesome liason between Rubyists and Apple. There's definitely real belief in Ruby at Apple, and that's awesome.

But everyone who uses Ruby on OS X knows that you can't use the version that ships with your machine. Apple's upgraded its Ruby support for Leopard, and that's cool - it's good that they finally fixed the problem people were complaining about in 2005 - but there's a fundamental flaw with the whole idea. Nobody's complaining about that problem any more, because we're all using up-to-date installs, in most cases thanks to MacPorts. Apple tried to fix the problem from 2005 and just created a different problem for 2007.

Apple's latest OS ships with an improved Ruby, but it's not an un-crippled Ruby - it's just a less-crippled Ruby. Apple set up a custom install so they could get the latest Ruby into the latest OS X. They included features in their build that were not even part of any official release, as of that build. But they also skipped over the gem_server function of Ruby gems - which gem server replaces in the next release. I'm already using a pre-release version of that next release on my machine; that release is not far away. They installed Rails 1.2.3 as well, and the next release of Rails (2.0) isn't far away either.

The next release is never far away in fast-moving open source communities, and the Ruby and Rails communities both fit that profile. The Ruby and Rails schedules operate totally independent of the OS X schedule, and lumping the three of them together in any way at all is illogical wasted effort. This happens because Apple thinks they're adding a feature to a product. They need to realize that isn't the case. What they're actually doing is supporting a community which uses their platform.

As a feature on a product, the improvements to Ruby support on OS X might have looked great before the product shipped - it must have seemed brilliant a year ago when they were planning it - but in real life, the only people who want this "feature" on this "product" are the members of a community who will modify the platform if it doesn't suit their needs. And obviously, it won't suit our needs. Giving us something functionally useless which still requires manual package management is really just silly.

Compared to what they gave us last time, what they're giving us this time is great - but that comparison is a mistake. They shouldn't compare what they're giving us to what they gave us before. They should compare what they're "giving" us to what we're actually using. What they would realize if they did that is that we never use the Ruby they provide us, because it's always inferior to the Ruby we can install ourselves. Therefore, "giving" us anything (except real package management support) is just a silly waste of time.

What Apple really needs to do is say, some of our customers are regular humans who want a product with features, and some of our customers are open source power users who want a powerful platform. By failing to recognize the existence of this second group of customers, they've released an OS which provides shiny new features for open source power users. But open source power users build their own features - by definition - and this shiny new "feature," Ruby and Rails support, is almost already out of date, on the day of its release. Over time, it's absolutely guaranteed to not meet the community's needs, because the basic assumption Apple made was wrong.

Apple needs to make a fundamental distinction between features they provide and communities they support.

If they had made this distinction before they released the iPhone, they could have avoided an utterly correct class-action lawsuit as well.

Steve Jobs is very, very smart, but if you think about it, it makes perfect sense that a company founded in the 1980s still thinks of software as something that comes from big companies and goes out to itty-bitty consumers. This is basically the broadcast model, and nearly every tech company in business today knows that the broadcast model lost a lot of ground when the Web became mainstream. There still are millions and millions of consumers out there who want products with features, but that doesn't apply to anybody who buys a Mac so they can develop Ruby apps. Supporting a community is fundamentally different from providing consumers with features. In 2007, that should be obvious.

We shouldn't have had to write our own package manager, either. It's awesome that Apple embraces open source, but it would be cooler still if they understood it. In practice all this is easy to circumvent, but we shouldn't have to work around our computers to be productive. If we wanted that kind of frustration, we'd be on Windows.

Update: Chad Fowler says I jumped the shark. His note about updating Rails is true, and kinda obvious, actually - whoops - but in terms of the things in the comments about user control of the upgrade path, I think I've actually got a point. Both Chad and Apple (with Leopard's Ruby support) have done great things for the Ruby community, and I hate to be arguing with either him or Apple's awesome engineers, but I think fundamentally my critique stands. Apart from anything else, it applies equally well to the battle Apple fought and lost over third-party apps on the iPhone. The iPhone is primarily a consumer product, but it is also a powerful developer platform. Apple failed to recognize the second part of that, and made a lot of their own customers and developers angry in the process.

If you're just reading this to figure out whether or not you should use Ruby on Leopard, by all means, go with what Chad says. He's installed Leopard. I haven't. He's talking about Ruby on Leopard, and nothing else. I'm not. Apple definitely deserves kudos for the Ruby support, I called it awesome like ten times. But it's not perfect, and the imperfections highlight something deeper and more important.

Apple has a decades-long history of issues with third-party developers. That's what I'm talking about. It's not a new thing, and it's not constrained to Leopard's Ruby support. I remember reading similar anti-Apple screeds before I even got to high school. (I had weird reading habits as a child.) Apple has always had this attitude towards developers. It was bad in the 80s, but in a day and age when the line between customers and developers has grown much more blurry, it's really time for them to rethink that.

Update part 2: Rich Kilmer posted a very awesome and useful correction on the ruby-talk list. I stand corrected.


  1. I see your point, and I agree with the overall thought of it, but I don't know if I agree on how you got there.

    I think including Ruby is valuable for those who use it mostly to write little throwaway scripts.

    There are even people who will build simple applications for themselves (say, a book catalog, or calendar app) who might appreciate Rails' inclusion without caring whether they update or not.

    Perhaps those people don't make up a large part of the Ruby or Rails communities though...

    I know Apple does it to appeal to the broader community, but still, it's not quite useless.

  2. Or what about the designers who work with developers, for whom upgrading the whole system just to get tests running is a nightmare. Of course, if the build is broken and they have to re-install anyway, then it's back to your point. But if there is any chance it just works...

    And I haven't played with it yet, but the new ruby sounds much, much better integrated. Maybe I won't have to 'sudo port install' much this time.

    And what about having the cocoa bridge installed, and whatnot?

    So have you actually installed Leopard and found it laacking? Or is this just pontificating based on theory? ;) It just seems like you might be a little overly dismissive of the advantage of the literal ruby support in your zeal over your ideals about community support.

  3. I understand the points that Giles is (repeatedly) trying to make, but in his zeal to argue "the community" standpoint, he's either missed or simply refuses to see a much larger one.

    The larger point is that MacOSX is an integrated product, one on which a lot of effort has been expended to make all the various features fit together in an integrated way that is palatable to the much wider community of users and commercial developers who may not consider themselves to be "rubyists" at all, any more than people who use the Developer tools consider themselves to be "C-ists". The Ruby community Giles alludes to may consider itself to be more cutting edge and subject to rapid change, but it would be short-sighted to assume that this is the only community Ruby can or should cater to. As a language "grows up", it needs to consider stability and integration as worthy goals in their own right.

    We have already seen this at work with the Python community, one which is somewhat older and more mature than Ruby and who's "packaging requirements" are no longer driven by the "Pythonistas" so much as by the developers who are leveraging the ability to embed it and use popular Python frameworks like Twisted to deliver more powerful and flexible commercial applications. Those applications, in turn, do not expect the underpinnings of Python to change in anything but a controlled fashion (e.g. with a de-facto "no user serviceable parts inside" label) and, when they do change, to change in a fashion that is fully cognizant of the backwards-compatibility issues they may introduce. Apple has put considerable engineering effort over the years into avoiding the breakage of python-based applications, the success of that effort born out by the fact that most people are not even aware of what we had to do behind the scenes to make those version transitions seamless.

    Sure, we could have simply left Python unbundled and said "that's a 3rd party problem - you guys support Python yourselves if you want to use it", but that's not the easy formula for success it may appear to be. For one, if we extended that to its logical conclusion, we'd never ship anything other than C/Objective-C/C++, a sure recipe for eventual stagnation in the developer support space. For two, even if we assume those technologies are easily available by other means, doing this would significantly increase the overall memory pressure on the system as every application carried its own copies of Python and other technologies we took "the easy way out" on. The system cannot share and optimize the usage of such technologies if everyone has their own (possibly uniquely versioned) copy of them.

    Finally, I should point out that there's nothing about Apple's strategy which precludes the installation of another copy of Ruby and anyone desiring the always-latest-and-greatest has always been free to install their own version - we have hardly "taken that away" and it's hard to understand why Giles is so deeply offended (so as to repeatedly refer to it as "useless" and "a waste of time") by the notion of allowing users and developers, all of whom may have better things to do with their time, to avoid having to install Ruby themselves merely in order to learn it and deploy applications based upon it. Making that easy only enhances the Ruby community and, based on the positive feedback we've received, I believe the majority of that community both understands and embraces what we are trying to do.

    - Jordan

  4. Jordan - I called it awesome. I approve of it also.

    Anyway - first of all, if you work for Apple, please say so at the start of your post. Just to make it easy to read. Before I figured that out I was totally baffled. Initially I thought Jordan was speaking for the Python community.

    It's very illogical to say that I missed or refuse to see the larger issue that OS X is an integrated product when my whole point is that you have something which is both an integrated product and a developer platform, and you are treating it as if it were only an integrated product. My whole argument is that this perception of a "larger issue" is in fact an inaccurate perception.

    When you're providing a defense of a strategy which I'm describing as misguided, it doesn't make sense to tell me that I didn't know you had the strategy. I did in fact know you had the strategy. That's why I described it as misguided.

    I'm going to stop being pissed off and just assume you made an honest mistake. Here's my point, rephrased: Apple thinks OS X is an integrated product. Apple is mistaken. OS X is both an integrated product and a development platform. Providing bundled languages without package manager support enhances OS X only in its integrated product aspect, and not in its development platform aspect.

    However, bundling development languages is not something you provide for run-of-the-mill consumers, but for developers. The upgrade path for developers is not an if, it is a when. For "cutting edge" developers the when is very soon, for regular developers it is further away, but in either case, all developers need an upgrade path of some kind, and Apple's approach to bundling languages overlooks this fundamental requirement.

    I think your claim that upgrade paths are only necessary for "cutting-edge" developers was a deliberate red herring, an attempt to capitalize on the Ruby and especially Rails communities' reputation for arrogance and self-absorption. While there can be no doubt this is a serious problem, at least for Rails - much less so with Ruby - it's kind of ridiculous to say that only "cutting-edge" developers are going to need Rails 2.0 before you release your next OS. Today, only "cutting-edge" developers are on Rails 2.0, but everybody is going to upgrade sooner or later. I'm not favoring the cutting-edge here, and I think you knew that. I'm just talking about something which the cutting-edge find out right away and the rest of us find out later on.

    Finally, two comments have both assumed a much greater emotional response on my part than actually exists. I am not deeply offended and I do not have a zeal for community ideals. It's just that I can't believe it's really happening. It kind of boggles my mind. I'm sorry, but it does.

    I love my Mac, but this is just bad logic.

  5. I'm afraid we must simply agree to disagree at this point, so I'll not continue what threatens to be a debate in the comment section of your blog - it's really not the most appropriate forum.

    You claim Apple is mistaken about the intended role and purpose of its own products, and if you choose to believe that then I suppose there is very little I can do to change your mind. I will merely leave you with two words: Software Update. It may not happen frequently enough for your liking, or always target the improvement of those technologies you hold in highest esteem, but it's also illogical to assume that the next OS release remains Apple's sole delivery vehicle for improvements just because I suggested the option of "self updating" to those who wish to have such improvements even more quickly. You might at least give us some benefit of the doubt and wait to see how the situation develops? Thank you.

  6. Not the intended role and purpose of its products. Just the role and purpose.

    I don't mean to upset you, man, but you have to realize, I'm in a difficult position here. You're a fellow software developer working on something I don't know about, but you're also representing a company which illegally vandalizes its own customers' property. So I know a little about the context you're operating in and I want to be fair, but on the other hand, I kind of think I need to kick and scream a little to get anything from your mothership.

    If I understand your hints about Software Update, that sounds like a very cool move, one I'd probably agree with, but it's not entirely fair to ask for the benefit of the doubt when as far as somebody like me knows there never was any doubt. Nobody out here in ConsumerLand had any idea.

    Also, sorry, but unless a change to SU is in the works, SU is (at least currently) entirely Apple-driven. It sounds like you guys are spending money on a kickass chauffeur when what we really want is a clearer map. I mean what developers need from Software Update is so different it really justifies an entirely separate system, and one which will move more smoothly if we run it ourselves - e.g., MacPorts.

    Anyway, again, sorry, you sound as if you took it personally, I didn't mean it that way, but I have to disagree on the forum thing too. If we're debating what the role and purpose of Apple's software is, we're absolutely in the right forum, because that's what my post was about. I also think there's a lot of value in debating it, because when it comes to a question of whether MacPorts or SU is the best solution here, I really don't know the answer. Depending on how that question resolves, it could undermine or reinforce my entire thesis. But I have an unfair advantage here. If the debate proves me wrong, I can change my mind. If the debate proves Apple wrong, only one small part of Apple is actually listening.

    Anyway, I think there's money lost here for Apple and energy lost here for the community. People on both sides of a divide are re-inventing the same wheel. If some system from Apple emerges to continually update developer installs of open-source tools, the best thing to do is to expose the hooks, because obviously, there are developers to whom this matters much more than it matters to Apple. The MacPorts situation is probably actually a healthy one to some extent - why should Apple pay for building something only a few people will use? - but at the same time it seems counter-productive. Really what we need is a Software Update API.

  7. As a Python web developer I normally only consider the Python that ships with Leopard as suitable for use as a build tool. We have a lot of build tools available in Python land. I can install Zope, Plone or Grok with just a simple build task. The best part about having your own build tools (in either Python or Ruby) is that you are not tied to deploying your stack on just the Mac. I prefer to deploy onto a linux server for example. I can use the Python that is packaged by my linux distribution as a build tool to run the exact same build tasks that I ran on my Mac, and repeat the exact deployment on a production server. With this method you can always ensure that you have the same versions of everything on both your Mac OS X deployment and your Linux deployment. Also if you are manage multiple projects, it's valuable to make explicit which versions of which packages each one is running, and have an easy way of reproducing that configuration. This also works well with multi developer situations when you are trying to synchronize the upgrade of packages across the team.

    I can appreciate Apple wanting to supply lots of pre-packaged open source builds on Leopard though. Making more open source, more wide-spread and more readilably available is a good thing. Junior developers or people reading introductory tutorials who want to just 'jump right in' can take advantage of this software. If the Ruby on Rails community makes a good freely available Rails introductory tutorial for example, I would appreciate having a known, pre-installed version of Rails available to walk along through the tutorial with.

  8. I don't actually know enough about package management to speak authoritatively about this next bit. However, what I'm really getting at is it's weird that if you want to upgrade Ruby on OS X, you go and put a second Ruby on there. All my info is out of date as of yesterday, and I never buy tech products on the first day, so it'll be a while before I get any of the details on this. But I kind of feel like I must have written this post wrong because it doesn't seem like anybody's getting the point I want to make.

    I'll give it another go later. I don't know what part of it I said wrong, so it won't hurt to think it over.

  9. "I don't actually know enough about package management to speak authoritatively..."

    I think that's a big part of the problem here. You just don't understand what's actually happened here.

    There are two groups of people:

    1. Those who will happily use the Apple-supported version of Ruby (the majority)
    2. Those who will install their own version of Ruby (the minority)

    Both needs are catered for in Leopard.

    You thinking it's strange that to install a customised (or updated) version of Ruby you need to install a duplicate copy? Well, welcome to BSD. There's always going to be a nerd on any system (a lot of the time, it's me), that wants to install a new or patched version of something. Well, guess what? They can.

    You've fallen into the trap of becoming engrossed in your own world - so much so that you think that you're the majority.

  10. You've fallen into the trap of becoming engrossed in your own world - so much so that you think that you're the majority.

    That's incorrect. I'm aware I'm not the majority. I have no idea why you got that misperception.

  11. I'm aware I'm not the majority.

    Saying that you know you're not the majority is one thing, believing it is another.

    How could you see the change from Ruby being a second-class language to a supported "first-class language" (according to Apple) as being anything other than a huge win for the majority of Mac Ruby developers.

  12. Saying that you know you're not the majority is one thing, believing it is another.

    Look, man, just go away. This is an "is too! is not!" argument. You're saying I think I'm the majority, I'm saying oh no I don't, you're saying oh yes you do. It's like we're four years old.

    I wouldn't tolerate that in person and I'm not tolerating it here either. Just fuck off already. I'm sure you know something I can learn, and I want to learn from everyone, but you people are fucking assholes. I am so tired of blog comments. I just can't stand this time-wasting bullshit.

    If my blog bothers you, JUST READ SOMETHING ELSE. The Internet is FULL of blogs. Go read a blog you like instead.