What I want to talk about here is a simple statement that I believe to be true:
The best platforms are written by the people who are forced to invent them as they make a product.
Years ago I learned a bit about J2EE; never actually wrote an app using it, but enough to get a sense. I came away with the very strong impression that the people working on it were driven by committee, with managers in their respective contributing corporations telling them what to do. They weren’t the same people out in the field writing apps using it, day in and day out, under time pressure to produce as much as possible. On the other hand, from Ruby On Rails Wikipedia:
David Heinemeier Hansson extracted Ruby on Rails from his work on Basecamp, a project management tool by 37signals (now a web application company).[10]
Now, I’ve never written a Rails app either, but it’s pretty clear from the Internet which one of these wins. Another excellent example is the Amazon Web Services. Amazon had a lot of this internally because they were forced to in order to make a web shopping site before CEO Jeff Bezos made the key decision to spin it off as a platform.
And the most topical example here – GTK+ was originally spun out of the GIMP project because Motif sucked. Anyways, some food for thought. Basically if you’re one of those people in the trenches writing a platform – you should consider asking your manager to switch to writing apps for a bit. At least hopefully this blog post reminds me later that I have a few GTK+ apps that I really should get back to hacking on…
Colin Walters 
I’m increasingly of the opinion that once you have your side-effect platform you still need the folks working on the platform to do some of the type of work that lead to the platforms creation otherwise the platform engineers can end up naval gazing and solving the wrong problems.
Yeah, or possibly rotate people between teams periodically. It may not be possible to do a full rotation because some people are much better at platforms and some are better at apps, but at least rotate the people who can do both.
And if anyone is looking for an app to write please feel free to drop us a line 🙂
https://live.gnome.org/Design/Apps/
I believe this is true as well. it’s a lot like “de facto standards are better than de jure” – those standards that are agreed upon in practice are better than those handed down from on high.
> And the most topical example here – GTK+ was originally spun out of the GIMP project because Motif sucked.
Yet Qt was designed as a toolkit from the start and people who tried both Qt and GTK+ tend to find Qt the better toolkit to work with. (And yes, I worked with both, and yes, I’m one of those who prefer Qt.)
not so sure about the java v. ruby comment. there are 7x more java jobs than ruby jobs in boston, for instance, according to indeed.
This is not something I’d put on the “platform” level, I’d put it on the API level. – In fact, people that invent any API should be made to port at least 3 different applications to that API so they see how it works.
For example, porting a bunch of apps to Cairo from GDK drawing taught me a lot about missing convenience APIs or functions that didn’t make sense.
And I agree: If you ever made me write an application, I’d probably turn it into a platform. At least that’s what’s happening to all the code I’ve written so far.
Hmm. Having users you’re designing for certainly helps. That said, I’m not convinced it’s absolutely necessary, nor of course is it sufficient. JavaScript succeeded for a bunch of different reasons, but it certainly didn’t succeed because it was forced into existence by Netscape’s needs in creating their product, in the sense you mean it. And in sort of a contrast, XUL has enjoyed rather less success despite Netscape forcing themselves into it to ship a product.
It seems to me you need at least two more things for a platform-extracted-from-a-product to work. One, as Joshua notes above, you need people who care about the platform, who put work into it. At Netscape (and Mozilla after, pretty much), people worked on the web parts, but the platform parts like XUL received less attention. (Probably even more or less justly.) It’s at least partly for that reason that Gecko disabled XUL on the web. Two, you need people who take the broader view, so you don’t end up designing only for your own use cases. These might be the same people as the platform people. Or it might be a subset of them. But when your only use is a mail client’s tree view of email, you end up designing an awful lot around that and neglecting things you don’t need (even things you might later decide you need, like inline-editable folder names in a mailbox tree). Everything I’ve heard says this goes a long way to explaining why nsITreeView is the huge monstrosity it is, for example. And it goes a long way to explaining why most XUL-based projects end up feeling a lot like web browsers.
But you have to be careful and sensible when you build a new platform. Otherwise you end up with something like this.
“Yet Qt was designed as a toolkit from the start and people who tried both Qt and GTK+ tend to find Qt the better toolkit to work with”
I don’t think this is universally true if at all and I don’t think you have any data to support your claim but even if true doesn’t disprove what he said because Qt was written to solve real world problems and not developed in a vacuum.
Havoc Pennington talked about this many years ago, on one of the GNOME mailing lists I believe. Maybe it was desktop-devel. Something about not accepting new API that hadn’t been in use yet. I still think about it from time to time.
Hm, Google wasn’t of much help there.
Qt vs. GTK+ – one big difference is that C++ has much more in-language support for extending the language. A more fair comparison would be of gtkmm and Qt.
But honestly, after having worked with HTML + JS for some years, I think the simple-building-blocks-and-powerful-styling approach of HTML is actually superior, despite browser incompatibilities. Sure, it’s faster to slam a simple UI together with GTK+. But not many problems actually fit well into that simple UI thinking.
Pingback: GNOME as a platform « Colin Walters
“Now, I’ve never written a Rails app either, but it’s pretty clear from the Internet which one of these wins”.
To me too… having used both of them, J2EE is better designed and better documented. Win.