I'll try to address some of the issues Havoc presented. Of course, I'm a Mono developer, so I'm biased, but hopefully people can see my arguments are more on the technical side than advocacy.
No rewrites please: this is a very important point: we can't just throw away the current code: we need incremental changes to not disrupt stability and compatibility. I'll just note that using Mono (and C#), interoperability with existing C code is much easier than with Java because of P/Invoke.
Calling managed code from C/C++: Havoc says it's hard, but Mono
provides an easy to use interface to do that. Mono is designed to be
embedded in existing applications, not just as a runtime for standalone
completely managed programs. Also, it would be easy to create
a shared library and header files to access managed methods seamlessly:
they can be automatically generated thanks to the use of Reflection
and the Mono embedding API.
I'm not sure a "simple native component system bridge" would solve
the issues, mostly because simple systems are always found later to
be incomplete, they get changed and become big, but with all the design
warts needed to make a simple design work for not-so-simple constraints.
A minimal Mono system is currently about 2 MB on disk, but no effort yet has
been put into reducing it (and I think it's entirely possible, we have been
busy implementing features and leaving aside space optimizations). Of course,
since the default build of the core assembly has lots of features, much of
the reduction in size could be achieved by trimming features that other
systems don't have:-). Even without trimming, most people will concour that
2 megabytes of disk space for a shared component is small enough in a
desktop setting (and applications compiled to IL code are usually much
smaller than comparable C apps anyway).
Community should decide: of course, I agree. Anything that is pushed
down our throats by somebody else is not going to work for the free software
and open source communities. The solution will need to be choosen because
it actually solves issues the developers and the users see. Java had several
years to try to attract developers from our community and it had some success
in some niche areas (not for desktop applications, though). Mono has just
started, but from the comments of the developers that actually used it to
write new applications or port existing ones from C, it looks like we are
on a good adoption path (even though we didn't release a 1.0 version yet,
we are still working on debugging support and documentation is sparse).
Havoc fears the adoption of Mono or Java for the desktop would alienate people and cause forks. I don't think that will happen with Mono, because Gnome will continue
to have a diversity of developers who'll prefer using the C libraries directly:
Mono allows to keep and interoperate with existing code very easily and we want
the migration to happen incrementally, so at first only end-user applications
would be written in managed code, while the foundation would still be in C
(at least, enough of the foundation to have people happyly writing their own
apps in c or with the existing bindings). At that point, when a managed execution
environment has proven itself to both developers and users (hopefully) we could
start discussing about using it for the foundation, too, if that makes sense.
I think Mono is positioned better here to allow this incremental shift of
both development and espectations towards a managed runtime.
Problems with a .Net clone: Havoc claims that MS controls the platform
because, even if the core is unencumbered, some assemblies are tied to MS
technologies and there is non standards body or community momentum to build
alternative solutions for a complete platform. Well, considering that until
a couple of months ago there were 5 people developing mono, we have achieved a lot,
not only in the implementation of the runtime, but also, thanks to the large
community contributions, in other areas, such as Gtk#, database connectivity,
security. There is already a large body of code that is completely independent
from the MS stuff. Besides, I don't see anywhere an assurance that Java and
all the libraries included with it are unencombered, so this is not an argument
that applies to mono only. Sun likely has several Java and JVM-related patents,
so a free software implementation of Java is no less a possible target for
patent lawsuits than Mono (and probbaly more so, since the companies that
submitted the CLR and C# ECMA standard agreed to license the patents needed
to implement the technology on a RAND basis and additionaly royalty-free:
AFAIK Sun didn't do any of that). Sun went to court to defend Java's purity:
will it also go after free software implementations of it if they want to
innovate and diverge from the spec?
Anyway, as an example: MS have their own Java-on-.Net
compiler and runtime system. Mono didn't implement that and uses instead the
excellent IKVM.NET free software JVM implementation to run Java code.
Innovation:
It should also be noted that we (as in Mono developers) are very open to
input from the community about changes to the runtime and base class libraries
that could be needed to better support new features, independently from what the
MS runtime does (the topic came up, for example, about supporting dynamic
languages on Mono). Of course, the programs wouldn't run unchanged on the MS
runtime, but we can't have it both ways: if we have to innovate we'll be the
first to be able to run such programs and maybe later MS will adopt the same
technology:-) The only consideration is just this: not breaking gratuitously
the compatibility, because that always has its cost. Most of these changes
can simply happen in the same way gcc introduced extensions to the C language:
first just gcc users could use them, later some were adopted by C99.
Of course, since we've been busy implementing the base platform, we didn't have
much time to propose and implement innovative changes, but expect changes
in the next few months (hopefully also from the community involvement).
There is no need for us to just wait for MS to implement something and then to
re-implement it as free software. We welcome your contributions in enhancing
Mono in ways that can benefit the free software community. We should also consider
that ECMA standardizes existing practices (hey, where did I hear
"Show me the code!" last time? Yep, in the free software community):
we're willing to assist people in implementing prototypes of innovative
changes in the CLR using Mono as a base and submit them to ECMA for
consideration.
Compatibility with the devil:
We (as in Ximian/Novell
and AFAIK also many mono contributors) will try to keep up with changes done by
MS to the platform mostly because it enables people to move from the MS platformto a free software platform more easily: in the next few years developers on MS
will be forced to develop for the managed platform and we'd like to offer them
an alternative to escape to the free world. I think this will be a good thing
for the free software community, but I can see other free software developers
not caring. I can live with that:-) Just don't use it as an argument against Mono:-)
Havoc notes that ECMA defines only a subset of the .Net platform and that it maybe too controlled by MS. Even if MS would try to undermine the changes we'd submit
to ECMA for consideration, this doesn't mean we can't have our own, community-driven
standards effort for enhancements to Mono and for the development of independentclass libraries. Let's discuss how can we best build a standardization effort.
In Mono there are two different stacks of code: the MS-compatible ones and
the free software/community one. See the picture. Free software
people can just ignore the MS-compatible bits and let the developers who
want to port their code from Windows to Unix systems worry about that.
Spelling out the options: I'll just note here that one of the options
is simply to use Mono and allow people who prefer the Java langauge to use IKVM
as a bridge: this may be the best of both worlds. A free software foundation
that doesn't exclude (choosing Java would exclude C#, since there is no way
to run C# code in Java or any of the other languages that target, or will target,
the CLR).
Havoc claims that "Anything which is defined as a .Net clone appears to not be
viable", because it would speedup the adoption of MS technology. I think that
for people who develop for the MS platforms what Gnome will choose is largely
irrelevant. Besides, Mono enabled people to jump from the MS platforms to
the free software and open source community. So far it has been a win for us,
judging by the contributions we had to Mono from formerly MS-only-oriented
developers.
Anyway, the solution to that is simple: just don't call Mono a .Net clone:-)
Mono is open to input from the community for enhancements: if differentiating
mono gives benefits to the community adoption and to Mono as a development
platform, I'm all for it (just let's not break compatibility gratuitously).
Havoc says: the open source Java subset is something we could start using today,that nobody has any fundamental reason to reject. Well, using Java as the foundation
has issues, the first of which is that it doesn't easily allow incremental migration
to a new codebase. It also excludes C#, since no JVM can run C# code. I think
starting out with the Mono core would be better, both for interoperability
with exisiting code and with Java, too (using IKVM).