Open Source vs. Closed, OS X Just-Right Blend

Interesting… more than 500 emails on the BeOS Refugee articles, and for the first time someone has pointed out an embedded puzzle in my thinking:

On one hand I talk about how I believe in the open source philosophy, benefit hugely from the fruits of open source efforts in my daily work, and always support collaborative development as a general concept.

On the other hand, I know from experience that closed source development models under a single control structure, with a single unified vision, are capable of producing a better user experience, more cohesive design, etc. more quickly. Despite best intentions, open source efforts are inevitably tripped up by fragmentation or bad communication resulting in a “cobbled together” atmosphere in the user experience.

The email I received subtly implied that there was a hypocrisy in my thinking here, but I see it more as an irony. And on further thought, this probably has something to do with my attraction to OS X – it’s the perfect blend of open and closed source development models – closed at the desktop level, where the user experience matters, and open at the command line level, where collaborative efforts work best. Hmm….

10 Replies to “Open Source vs. Closed, OS X Just-Right Blend”

  1. Hmm, while open-source projects are more prone to fragmentation, this is not an inevitable development. Projects like Python, Perl, or my own LDMud do have a single control structure; and while fringe variants exist, they tend to stay at the fringe.

    On the other hand closed-source fragments just as badly as open-source (at least from the user point of view); it just happens in neater packages. One example is the myriad of incompatible instant messenger programs.

  2. You make a very good point about closed source projects that fragment – chat is a great example. Perhaps one reason we think of closed source as being generally unified is because between MS and Apple, the field has been virtually closed to genuine variety of the sort you get in, say the automobile market. Thanks for the feedback.

  3. The chat problems comes from the non existance of a standard. The last chat standard I know of is the IRC RFC’s, no Jabber seems to be the winning solution because the IETF has set up a working task force concerning IM , they will focus on writting the RFC, once written you’ll see some unification on this front.

  4. I agree that Apple rocks in the user experience arena, but I’m not entirely convinced that this is due to closed vs. open source.

    An open source desktop environment could be just as usable, if it really mattered to a group of talented developers. I suspect the fact that it doesn’t matter enough (yet) is more due to a macho, “we don’t need no stinkin’ usability,” “real (wo)men use the command line” attitude on the part of alot of open source developers than anything else.

    However, it looks like steps are being taken in the right direction. Witness Owen Taylor’s Configuring the Red Hat Linux Desktop.

  5. I disagree. I think there are many Linux desktop hackers and engineers who care about creating a good user experience, but have been unsucessful because it’s just too difficult to gather momentum around any particular configuration. I think RH’s letter ( the one you point to) provides evidence of this – RH tried to create a cohesive user experience and they got a whole lot of flack from the user base. Yes, they press on regardless, so that’s commendable, but still.

    That notwithstanding, do you think RH will ever be able to generate a BeOS-quality or Apple-quality desktop experience? Sure it would have happened by now. The only such project – Nautilus – tanked big time.

  6. >do you think RH will ever be able to generate a BeOS-quality or Apple-quality desktop experience

    I don’t think so.
    Red Hat, who’s “desktop-oriented” new distro is actually pitched against company desktops and workstations and NOT for every day users, it would be the best yet Linux desktop distro. However, that doesn’t mean that its desktop experience will be better than OSX or WinXP.

    >The only such project – Nautilus – tanked big time.

    Yeah, a huge lot of that engineering team now works at Finder… ;-)

  7. ;) Hi Eugenia… I’m very excited to see what kind of goodies the new Finder (aka Tracker) team have up their sleeves for us. A few niceties in Jaguar, but I really think we have a lot more to look forward to on that front.

  8. Yes, it’s true the Linux crowd can be quite contentious about their favorite desktop/distro/floorwax/dessert topping ;) However, if a group of talented developers got together with some interested human factors/cognitive psychology folks and decided to just go for it – it could be interesting. They’d certainly have to adopt an attitude of “do the right thing and if someone doesn’t like it, tough”, however.

    Now why they’d want to, since it most likely wouldn’t make any money, is another story. Maybe some graduate students at a school with a strong Computer/Human Interaction emphasis (e.g. New Mexico State Univ.) could take this on as a research project… Those folks do cool stuff all the time for no money (I used to be a graduate RA and I know ;)

    As for the RedHat project, no – it might make it more usable, but it won’t be up to Apple or Be standards for “Joe Average User”

  9. Money isn’t the motivating factor behind the best open source development initiatives. I think that after Nautilus tanked, they gave the source code back to the community, and the whole thing fell apart in in-fighting, as is typical in open source efforts.

    You’re right – this is perfect for grad students. As long as everyone is on the same page, good things can happen.

  10. Heroic Development in general (closed or otherwise) tends to only work when there is a (usually charismatic) leader that everybody accepts and looks to for inspiration, direction etc.

    This is easier to do in closed development since this usually involves companies were people meet face-to-face everyday and projects often have appointed leaders.

    In an online/remote development model (which open source often is) this is far more tricky to pull off.

Leave a Reply

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