Restarting Innovation
The far larger group losing out when Apple absorbs a market is the end users of the OS. How can that be, when Apple has provided an Apple-branded solution for a given need? The problem arises from the fact that Apple is not married to any particular new market. As such, the provided solutions are seldom deep. They do the job for many, perhaps even most users, but as with all software, they’re seldom complete.
This is true enough, but I’m not sure that I like the suggested solution—that Apple should factor out more of its applications’ functionality into frameworks.
First, Apple seems to have its hands full working on the existing OS. There are buggy APIs that don’t work, even though we’ve crossed into x.x.10 territory. There are short-lived APIs that weren’t designed properly the first time. There are also potential APIs and plug-in interfaces that would give developers access to areas of the OS and Apple applications that are currently inaccessible without reverse-engineering and reliance on unreliable, private interfaces. I would much rather that Apple work on these things—because they are issues that only Apple can address—than on writing framework code that developers could write themselves.
Second, I question the usefulness of these potential additional frameworks. I think WebKit is a special case. Lots of applications need Web functionality, and it’s a ton of work to write a good Web engine. Thus, WebKit was a great idea. I don’t think other potential frameworks—even MailKit—would meet these criteria. (Fewer applications need mail functionality, and implementing POP, IMAP, and SMTP is much easier than handing HTTP, HTML, CSS, and JavaScript.)
Third, it’s not clear to me that such frameworks would help the ecosystem. In many cases, your application would want to add functionality that goes beyond what’s in the framework. It’s tough to write a framework that’s general enough to be used in unexpected ways. It might incorporate design decisions that limit its flexibility or have bugs that Apple didn’t encounter but that are on the critical path for what you need to do. If your application relies on a framework for its core functionality, you are at Apple’s mercy.
To build a really innovative application you may have to start from scratch, and then you’ll wish that the framework didn’t exist. If the framework provides 70% of what you need, you’re now spending 100% effort to get that extra 30% ahead of your competition. Because of the framework there are now lots of 70% applications that took a weekend to build, and some of which are free, so it’s harder to differentiate your product. In the next OS release, the framework will probably do more, so once again you’re in the position of competing with something free from Apple—only this time it’s a developer product rather than an end-user product. Even Omni decided it couldn’t do this, and newer versions of OmniWeb are based on WebKit.
Having an Apple framework is a good way to guarantee that there will be lots of applications that have many of the same strengths and weaknesses as the underlying Apple technology, but this may be more of a monoculture than the healthy ecosystem of “deep” solutions that Paul desires.
I don’t mean to say that having more frameworks would necessarily be bad, but I don’t have a strong feeling that it would be good, either. The rise of the OS is inevitable, and there are no simple solutions. If Apple had created a framework for dealing with iPods and the iTunes store, Audion might still be under development. On the other hand, if there were an AirPort Express framework, you wouldn’t need Airfoil to play music from Audion on your stereo.
5 Comments RSS · Twitter
OmniWeb is based on a modified version of WebKit though. So it would probably work out well if the new frameworks were also open source, so that they could be modified to add the final 30 %.
All I think we really need is more and more application data to be held in databases, and some documented schemas.
This is based on the observation that people used to think they wanted software compatibility - 'why can't I run program X on machine B'? Over time they've realised what they actually wanted data compatibility, and gradually standard formats emerged.
But there's still some data stuck in application specific silos - occasionally - as with Pages, iMovie, iDVD, Photoshop, that makes sense as they're 'working' formats where you 'publish' to another.
JulesLt: I agree that data formats are important, but documenting them doesn't solve all problems. iPhoto has changed its library format several times, for example. I'd rather see a plug-in interface and an API to access the contents of the library. Apple did document the Keynote 1.x schema, but now that technote is marked as a legacy document. Word's XML format is documented, but it's so complex as to be inaccessible to most developers. I think it would be great if other applications could access data from Pages. Its "working format" is more interesting than the output format if you're trying to automate anything.
I'm commenting on: "To build a really innovative application you may have to start from scratch, and then you’ll wish that the framework didn’t exist."
There is a huge difference between Webkit, and other frameworks from Apple, for example, NSTextView: Webkit is open source. You can get it from http://webkit.org .
So, your argument used to be true, until Webkit.
If you want to write a word processor with additional features, you have to throw away the additional 70% that NSTextView provides and start from zero, doing a huge amount of work just to get up to the level that NSTextView provides. If you want to write something that overlaps with Webkit, you can start with the source and build your app.
As a programmer, I say: yes please, Apple, give us more frameworks, with source code, and we'll give the people more apps.
