In article <[EMAIL PROTECTED]>, "Brendan Eich" <[EMAIL PROTECTED]>
wrote:
>> This is quite an opportunity. It's a select few projects that see that
>> level of ubiquity. And yet mozilla.org seems indifferent, if not
>> altogether dismissive of this situation.
>
> Who @mozilla.org has been dismissive? Or indifferent, for that matter?
When I look at GNOME, I see a situation where different companies really
are working together to create an open system that's easily accessible to
developers--whether those developers are working at another company, or
just hobbyists working in their spare time. In general, it is quite clear
that an effort is made to keep the libraries as accessible as possible to
developers who want to leverage them.
Netscape, on the other hand, seems to operate under the philosophy,
"We'll make what we need for our stuff and we'll do it in the way that is
most convenient for our way of doing things, and the world can take it or
leave it."
This is directly related to the relatively low level of community reuse of
mozilla.org's code. Developers right now have to jump through some
serious hoops if they want to leverage mozilla.org libraries. JavaScript
isn't too difficult, but it's still harder than it should be. As for
NSPR, XPCOM, and Necko... Well, the initial investment required is high
enough that many developers will simply dismiss these potential solutions.
> I'm rattling cages by email, and drivers are following the API freeze
> work that valeski is leading (see mozilla.porkjockeys). mozilla1.0
> needs stability, performance, and frozen APIs to existing
> implementations -- not any particular new feature (as the roadmap says).
>
> I don't speak for netscape.com, but I'll say what all staff and drivers
> @mozilla.org know: being a system library on many distros is a victory
> condition, and it requires API freezes and a decent versioning story.
> We're working on the API freeze part, and still limping along on COM's
> versioning story. Suggestions?
libtool will solve your versioning problem for Un*xen for non-XPCOM
modules. But as Ari indicated, static APIs and versioning aren't the
biggest barriers. It's the accessibility.
Braden
