Colin is one of my Greatest Debian Heroes, and has joined a number of
my other (sometimes historical) Debian Heroes at Red Hat. I don't like
the personal walls some people put up or believe in between Red Hat and
Debian, whether or not they like the particular bits shipped. Thing is,
Red Hat and Debian's political worldviews are much closer than most of
the other "pragmatic" distributions.
Don't diss the people, people. :-)
#
The Language Question
According to Dave, my
release hat is "rigid and boring", but it turns out to be quite useful when
approaching The Language Question. Thus far, no one seems to have covered
use cases or categorisation. So here goes... From my perspective, we have
perhaps four major categories:
Developer Platform
This one is super-thorny, because most of us want to keep our language
neutral libraries and permit lots of choice on top. This will be the last
domino to fall, as any discussion of alternatives down here would involve
far-reaching changes up the stack and the "language platform" issues Havoc
raised (such as using language-platform-native database APIs and so on).
I think we can safely limit the language discussion to other categories, and
not worry about how it affects our platform at the moment.
Desktop
Lots of people are cottoning on to the fact that I think the Desktop is too
important for its own good. But, while that is still true, we have to accept
that it's the crown jewel. Everyone ships it and hopefully everyone buys
into what we ship (which we can often choose accordingly), so the Desktop is
"don't rock the boat" central.
That makes Java and Mono difficult choices in the Desktop for the moment
(though they are certainly worth discussing), but there's been very little
disagreement with the use of Python as a transient, small-project language.
There's been interest in using Python for the Control Center for some time,
amongst other places, but it would probably not be appropriate for a large
chunk of software such as Nautilus or the Panel. At least for the moment -
lots of people are still flinching from the Red Hat Update Agent experience.
To a certain extent - ie. Java and Mono - this leaves the question wide
open, and there's no question that we should continue to discuss it. But the
Desktop is one area that we must all roughly agree on... Let's not fuck it
up by being impatient.
Independent Free Software Hackers
This is Mad Max territory. If bindings exist for any language, hackers will
come, and so they should. We shouldn't do anything to discourage this. For
one, it's cool, but... it may also open up interesting markets to us in
areas such as scientific research. We're not providing solutions or
alternatives for this group, we're just helping them along their way.
So we can basically avoid this category with the "use anything!" answer, and
it shouldn't harm other messaging.
Custom or Internal Software Developers
These kinds of developers are using C++, Java, VB, Delphi or increasingly,
C# and .NET. On one hand, we have to sell platform independence or partial
migration, but as more and more internal projects begin on Free Software (OS
or development) platforms, there will be greater acceptance of opportunities
in our ecosystem.
So it would be hugely advantageous here to have a good story on C++, Java
and Mono, along with other alternatives such as Python, Perl and PHP. Will
any forward motion here have a detrimental effect on GNOME, via interested
stakeholders (the companies)? It doesn't seem so to me, on first inspection.
Different companies can support what they will for their own GNOME-based
products (Sun, for instance, sells Java as its desktop development answer,
and is making sure it integrates into GNOME fairly nicely - it's a bummer
they don't support GNOME itself, but hey).
We need to provide (and "sell") great answers to succeed in this market, but
there is no harm in having alternatives. The more rigid ISV answer below may
help direct some of this morass anyway.
Independent Software Vendors
ISVs will have similar requirements to Custom/Internal developers, but with
a more rigid approach, most likely. I'm less familiar with ISV problems than
I am with the above categories, so perhaps someone can help fill this in a
bit better.
What I do know is that we are probably best off positioning a few select
tools for ISVs that we know will integrate well into GNOME. We start with
C/C++, add a managed language for rapid development, and toss in a scripting
language in for macros and desktop scripting as well as transient apps and
prototyping.
This is hard-sell territory, and probably not an area where the community
will have much direct impact (or even interest). But can we leave all of
this to the major stakeholders, without being sidelined in the process? Not
sure, but I'd like to think we can help forge some common answers along the
way, and keep our tight crew together.
Conclusion?
Is there a conclusion here? Not really. I just want to encourage further
thoughts about use cases in this discussion. We don't make these decisions
in a vacuum! I certainly don't want to rule Java or Mono out of the equation
either, even though we're going to need a lot more discussion to sort those
out safely.
But a closing thought on the Java and Mono topic... What I'm seeing out here
is a lot of involvement and selling - even carroting - from Novell/Ximian on
the Mono front. Supporting f-spot development, the GTK+/GNOME bindings, some
plugins for various programs, and the big one - iFolder/Simias. To some, the
iFolder/Simias release is a great big Mono-shaped community carrot, giving
us a tasty-looking solution to one of our big-interest problems.
Is Sun doing anything to get the community interested in Java? Not that I've
seen. Mono may win over the community, not for legal or technical reasons,
but simply through lack of attention from the Java camp. I wonder how close
the Java and Desktop teams are within Sun...
Update: In reply to Luis, I was definitely talking about the carrot effect, without accusations about a carroting intent.
#