Nat Friedman: Mono is doing really well. I started hacking in Mono a few months ago for some personal projects, and was very impressed with how complete and usable it is. There are a few software houses and embedded developers who may be using Mono as the basis for their .NET products soon, too (announcements to come if we get the deals).
One of the really cool things about Mono is that you get a high-level,
garbage-collected language which can wrap C and C++ trivially. For
example, if you want to use the GNOME-VFS library from your C#
application to find the MIME type of a given file, you just do this:
[DllImport ("libgnomevfs-2")] extern static string gnome_vfs_get_mime_type (string text_uri);
And then you can use the gnome_vfs_get_mime_type() function from your C# code. That's it -- that's all the code you have to write. This is way better than Java Native Interfaces (JNI), which requires you to compile a wrapper class before you can call into C, and needs some other boilerplate code. In C#, for many cases, you don't have to worry about header files or wrapper classes or anything.
This has two important ramifications.
First, Mono applications can easily use existing C-based GNOME components and take advantage of all the hard work that's gone into them. So as Mono matures, people will begin to use it to write desktop components that take advantage of all the hard work that's gone into some of the meatier GNOME libraries, as well as the nifty language features of C#. Gtk# is a good example of this, but I think we'll start to see things like GNOME-VFS, GConf and the Camel messaging library being used from Mono more often.
Second, this means that Mono can be the universal component hub, allowing you to use C objects from Python, C++ objects from Perl, and so on. This is possible because C#'s language features make it trivial to automatically bind C# objects into other languages. Check out Python Scripting for .NET: http://www.zope.org/Members/Brian/PythonNet/FAQ.html. There's also a Mono-based JavaScript compiler in the works (MS already has one, of course).
We're not going to make Evolution or any of our other products depend on Mono anytime in the near future. However, we are already prototyping new functionality in Mono (like the sidebar folder summary Miguel wrote), and in a year or so, we may feel comfortable enough to start writing new critical-path code in Mono. Certainly we won't do anything like rewrite currently-working components in C#. There won't be an all-at-once port of Evolution to Mono, for example.
What is pretty likely to happen in the near future is that we'll ship C# bindings for key things like the Evolution backend data stores -- your mail, your calendar, your addressbook, etc. -- at some point soon. This means the community can use Mono to extend Evolution and the desktop without all the hassle of diving into the web of C-based GObjects.
7. How is the market responding to your Red Carpet Enterprise product? What do you see as the biggest competitor to this product today
Nat Friedman: Big Linux deployments have reached the point where it's become a real problem for administrators that they don't have nice tools to manage their servers and desktops.
Red Carpet Enterprise has been really well received since one guy can install it in about an hour, and it makes it trivial to deal with software management issues like deploying updates and creating standard package sets for your various machines.
Amerada Hess is one good example of this, where one administrator is using RCE to single-handedly administer 300 Linux servers and desktops. This is what people need: an easy-to-deploy, easy-to-use tool.
RCE also has the nice advantage that it supports pretty much every major Linux distribution out there; this is especially handy in environments where you've got a few different distros in use.
- "Nat Friedman, Part 1"
- "Nat Friedman, Part 2"
- "Nat Friedman, Part 3"
- "Nat Friedman, Part 4"
