Putting the 'Mono debate' back on the rails

[Jeff Waugh <jdub perkypants org>]

Ni hao,

(Wow, this took a long time to write. Sorry!)

I hope that everyone is unhappy about the running thread about Mono on d-d-l
at the moment. Not because I want everyone to be unhappy - but I hope we can
agree that it has devolved into argument, that everyone's sticking their oar
in whether they should or not, and it's a real pity that we had to fall into
this straight after GUADEC...

Let's put the brakes on, step back, and aim towards finding a resolution. It
might not please everyone, and we have to be prepared for that - but I don't
think anyone here actually *wants* to have an argument. We want to find some
answers. So let's see if we can turn this discussion around and work towards
a resolution... then we can get back to changing the world!

One of the problems I've seen in this discussion is that we're finding a lot
of issues difficult to separate. We're conflating things, making it hard to
see the wood from the trees. There are all kinds of questions here that have
a lot of history, and there are some short term and long term goals or plans
that *have* to be separated out to be discussed in any sane manner. This is
not going to be simple, because there are no simple answers. We can't start
dismissing each other's input and approaching this like it's a black'n'white
debate - there are a *lot* of greys here, and we must approach it with that
in mind.

However, things *can* get simpler if we try to document and understand the
problems. We can work together to define the parameters of the debate, which
bits are complicated and which bits are not - I hope this list can go some
way towards clarifying things. Here's a separated list of the short and long
term things related to the 'Mono debate' that we have to resolve and a start
on nutting out the parameters of each. I'm sure there's more and it's likely
that we should turn this into a wiki page later.

I'm going to follow up with some process suggestions to see this through,
but first I want to get this out and documented. Here goes:


 * Should we include Gtk# in the Bindings suite?
  - short term
  - it hasn't been proposed for 2.16, but we could grandfather it in
  - the release management issues have largely been solved, aside from Gtk#
    not being split between Platform and Desktop (stable and unstable) APIs
    which is pretty important in terms of ISV/ISD communication and so on
  - bindings are a very important part of GNOME, and our value proposition
  - it seems that few people are concerned about Gtk# adopting the release
    process and other standards, then being included in our Bindings suite
  - a social/business/non-technical issue may persist regarding GNOME using
    or endorsing a Microsoft derived technology; some users/vendors may not
    appreciate that, to the point that they may choose to disassociate from
    the GNOME project (this shouldn't be dismissed out of hand)


 * Should we include Tomboy in the Desktop suite? (completely independently
   from the fact that it uses Gtk#/Mono)
  - short term
  - it has been proposed for 2.16
  - does it *need* to go in the Desktop suite at all? (genuine question, it
    may not be necessary to include Tomboy in the Desktop suite to achieve
    Tomboy's goals)
  - if we say yes here, we depend on the next question (but short term, the
    next question only starts to matter if we say yes here!)


 * Should Gtk#/Mono applications be accepted into the Desktop suite?
  - short to medium term
  - pathological case of 'Desktop suite pressure' (everyone wants their
    stuff in the Desktop suite because that's how you become enfranchised)
  - performance (memory and cpu) is a red herring here; we all *know* that
    we want to start using higher level languages for writing amazing GNOME
    software, so whether it's Gtk#/Mono, Python, Java, Perl or Brainfuck, we
    fully acknowledge that we're taking a hit for developer productivity and
    our ability to deliver awesome software to users. very few pieces of the
    software on the radar for proposal are central, 'always-on' elements of
    the desktop experience (think f-spot vs. beagle). performance will be an
    important metric for inclusion of any software, but it needs to be done
    on a case by case basis, not from a dogmatic perspective about competing
    platforms or the idea of using higher level languages at all. that horse
    has well and truly bolted!
  - can we resolve the dissonance between delivering a coherent Desktop (a
    goal of the Desktop suite) and suggesting that vendors deliver multiple
    vm/language/binding/runtime platforms to satisfy it, and demand that
    users stomach it too? (this has also been raised as a performance issue)
  - a social/business/non-technical issue may persist regarding GNOME using
    or endorsing a Microsoft derived technology; some users/vendors may not
    appreciate that, to the point that they may choose to disassociate from
    the GNOME project


 * Should applications built with anything in the Bindings suite be accepted
   into the Desktop suite?
  - short to medium term
  - do we want the central components of our software to potentially be
    written in five to ten different languages and/or runtimes/platforms?
  - this leads very neatly into the next question


 * Is it time to redefine the suites and/or 'franchise' the release process?
  - medium term
  - this is not just about new suites, it's about redefining the current
    Desktop suite by its integration interfaces and central components; we
    need to make current suites serve us better before kicking off new stuff
  - http://perkypants.org/blog/2005/05/19/1116533413/ (last few paras)
  - start slow: don't even create new suites to begin with, just make sure
    the small number of apps that want to adopt our process and standards
    right now can do so - new/further governance of suites can come later


 * What is the future of the GNOME platform?
  - long term
  - this (or at least, conflating this into other discussions) is how people
    start getting seriously emotional
  - as important as this is, we can probably explicitly rule it out of the
    discussion for the time being


Thanks,

- Jeff

-- 
linux.conf.au 2007: Sydney, Australia           http://lca2007.linux.org.au/
 
       "Microsoft treats security vulnerabilities as public relations
                        problems." - Bruce Schneier