Frameworks Versus Open Source Apps

The newest issue of Flaming Fireball talks about why open sourcing Apple apps isn't some sort of magical solution to adding or changing features. John is dead-on with his suggestion that scripting or plug-ins are a better approach in many situations.

I'd add that frameworks are sometimes a more complete solution. Safari is one of the best success cases. Apple didn't open source the app, but they did open source the important part: the WebKit (aka "Web Kit") engine. We don't need an army of Safari derivatives with minor differences. That's a mess.

As a framework, WebKit enables developers to use the guts of Safari in similar but ultimately distinct applications. Yes, someone could use WebKit to make a Safari clone with minor differences, but there's really no reason to do that. Instead, we end up with specialized browsers like OmniWeb that don't need to reinvent the basics.

High-end geeks might see complete source as fun to play around with and a path to some "super" version of Safari, but there's a lot of confusion that could result from that. Something that is nearly identical to the real Safari could end up on the hard drives of people that don't know any better.

On the other hand, I guess we could look at the fact that all of FireFox is open source but there's really only one version of the app that anyone knows about. There are other Gecko-based browsers, but not full-fledged FireFox clones. FireFox is a bit more of a design-by-committee affair, though.

The point here is that if we want a alternate derivative of Mail, we don't need the source to Mail itself. In fact, that's a tremendous amount of work for everyone involved. I think a public, supported Mail framework that provides all of the essentials of parsing, sending, receiving, renedering and so on is a much cleaner solution. It's easier for Apple, easier for developers, and results in unique apps.

There's even good financial motivation for Apple to do this. Making a new framework encourages developers to write apps that need a newer version of Mac OS X.
Design Element
Frameworks Versus Open Source Apps
Posted Jul 17, 2006 — 8 comments below


David Allison — Jul 17, 06 1456

Flaming Fireball == Daring Fireball

Zac White — Jul 17, 06 1457

I agree. I wish more things of apple's would get frameworkized. Also, Flock is a pretty big Firefox fork which is basically like Firefox with a bunch of web service plugins built in.

John Gruber — Jul 17, 06 1458

The "Flaming Fireball" reference was a reference to this.

Jesper — Jul 17, 06 1460

"Flaming"? :)

John Labovitz — Jul 18, 06 1461

There's plenty of precedence for Apple "frameworkizing" subsystems that were previously either embedded in an application or shipped as a private, undocumented framework. For example: InstantMessage, NSImage's support for reading RAW files, ImageCapture, PDFKit.

Although limited, there's even a public email framework: Messaging.framework, implementing NSMailDelivery. Obviously, that's only a tiny part of the potential, but at least there's something Apple can add onto.

The last couple of WWDC's I've attended had several announcements and details about "new" frameworks that were actually older private frameworks made public. It seemed to me that Apple engineers were interested in publishing more frameworks, if there was enough demand.

I think that Apple's frameworks is some of the best work they've done (with some exceptions, like SFAuthorization). It encourages new thinking about problems. Do we really need another email application? I'd rather have tools that can easily use standard formats and protocols, but transcend them towards something new.

Andy Lee — Jul 18, 06 1462

The "Flaming" may have been deliberate, but I'm pretty sure "FireFox" should be "Firefox."

Scott Stevenson — Jul 18, 06 1463 Scotty the Leopard

there's even a public email framework: Messaging.framework, implementing NSMailDelivery

I'm hear it doesn't work very well.

Stephen — Sep 05, 06 1740

It seems to me that this is part of the life-cycle of cocoa frameworks at large.
They start out as private in Apple apps, then when they are mature and robust enough that you can use them in unforeseen ways without needing an intimate knowledge of any "cooperative" classes, they get released.

Ever since disc-burning became an available framework and Project Builder's special tabbar became public every time I see a new feature in Apple apps that I think I can apply I say to myself "Give it a year or 2 and it will be NSCoolFeature" - It pretty much always turns out that way. I think the only reason it takes so long is that they are protecting us until the framework is ready.

I couldn't agree more that this is in Everyone's best interest. Developers use the latest tools to not be reinventing the wheel, customers have to buy the latest OS to use those apps, and the platform benefits because we end up with the neatest ideas because nobody is wasting their time implementing spell-checking.

Maybe the frameworks should be open-source, yes. Though then apple risks (I guess) someone finding a way for all Cocoa apps to run on linux and bam! But having a few open-source frameworks is a Good Idea, I think. But open-sourcing the app is completely counter-productive, because it allows people to expend their efforts working on existing products or worse, waste their time creating redundant YetAnotherBillysFavoriteTextEditor, instead of creating something new and creative with existing functionality. I for one would like to see that all the sudden my spreadsheet can include a calendar or my code editor sports instant messaging or file-sharing app can burn a CD - All for about 2 days-work on the programmer's part thanks to NSDiscBurning or NSInstantMessage or the iCal frameworks.



Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.

Copyright © Scott Stevenson 2004-2015