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.  #