使用 ECMA 标准：Miguel de Icaza 访谈
类别: ASP.NET教程 
使用 ECMA 标准：Miguel de Icaza 访谈
Dare Obasanjo
2001 年 12 月
摘要：在本次访谈中，GNOME 和 Ximian 的创始人 Miguel de Icaza 讨论了 UNIX 组件、Bonobo、Mono 和 Microsoft .NET。
Dare Obasanjo：最近您一直忙于发布 Ximian（英文）的声明，宣布创建 Microsoft .NET 开发平台（英文）的开放源代码版本。此前，您为 GNOME（英文）和 Bonobo 所做的工作使您受到了世人的广泛关注。您能否简单概括一下从早期项目到 Mono（英文），您在免费软件开发方面所作的工作？
Miguel de Icaza：在过去的四年里，我一直从事 GNOME 项目的各个领域的工作，比如：GNOME 项目的组织、程序库和应用程序。此前，我从事 Linux 内核方面的工作：我用了很长时间研究 SPARC 端口；这之后研究了软件 RAID 和 Linux/SGI。之前，我编写了 Midnight Commander 文件管理器。
Dare Obasanjo：在您撰写的 Let\'s Make Unix Not Suck（英文）系列文章中，您曾提到由于缺乏可重复使用的代码致使 UNIX 的开发长期以来受到束缚，您特别强调了 Brad Cox（英文）的“软件集成电路”概念，指出软件构建主要基于组合可重复使用的组件，也就是要编写可以重复使用的代码。许多人反对您的观点，他们认为 UNIX 的建立基础，是通过使用管道连接较小程序的输出，来使用可重复使用的组件完成程序构建。您对这一反对观点有何看法？
Miguel de Icaza：是的，这个问题已经详细刊登出来了。这里提到的“管道”严格说不能作为完整的组件系统。它只是一种使用某些常用协议（例如行、字符、缓冲区等）处理信息的传输机制。而协议只拥有信息流。
详细内容都刊登在那篇文章（英文）中。[[B]Dare[/B] - 请参阅“Unix Components: Small is Beautiful”。]
Dare Obasanjo：Bonobo 是您尝试以 CORBA 为基础来创建 UNIX 组件体系的产品，后来为何又转而开发 Mono 呢？
Miguel de Icaza：GNOME 项目的目标是补充 Unix 所缺少的技术，从而在桌面应用程序市场中更具竞争力。我们很早就意识到语言独立性的重要性，这也是 GNOME API 使用标准代码进行构建的原因。这种标准代码使得 API 可以被其他语言轻松打包。Unix 的大多数编程语言（例如 Perl、Python、Scheme、C++、Objective-C、Ada）都可以使用我们的 API。
后来，我们决定使用更好的方法来封装 API，于是就开始使用 CORBA 来定义组件的接口。我们还使用策略和一套标准 GNOME 接口对其进行补充，以便更轻松地创建可重复使用的、独立于语言的组件、控件和复合文档。这项技术就是今天的 Bonobo。C、Perl、Python 和 Java 都可以使用 Bonobo 的接口。
CORBA 擅长定义粗糙接口，而且大多数的 Bonobo 接口都是粗糙的。唯一的问题是 Bonobo/CORBA 接口都不善于定义小接口。例如，XML 分析 Bonobo/CORBA 组件可能没有 C API 有效。
以前我也论述过：
当然除此以外，我一直钟爱各种有关 Java 的事情，只是不愿让 Java 组合有一丝缺陷。
我们尝试通过配备公共对象基类 (GtkObject) 在多种语言中提供 API，然后根据 API 约定和格式轻松地对 API 进行打包，以用于其自身的编程语言。我们还对 API 进行基于方案的定义，用它自由生成包装。鉴于多种原因，这个解决方案还是有些欠佳。
对 CORBA 进行的跨语言集成有些类似于 COM，但是要付出一些封送处理的代价。它可以很好地处理非进程组件，但是对于进程组件，情况就不那么美妙了：因为没有可用的 CORBA ABI，所以结果糟透了。对于这个问题，我不想多说什么。
此外，我们还遇到了程序库的扩大问题。大多数程序库都能非常准确地遵循代码惯例，但偶尔也会违反惯例，或者我们采用了其他人编写的程序库，却导致了程序库的混乱：虽然功能强大，但实现了多个编程模式。有时是不同的分配和所有权策略，有时又要处理 5 个不同种类的“ref/unref”行为（例如 CORBA 本地引用、关于未知对象的 CORBA 对象引用、对象包装的引用计数）。这使我们陷入了巨大的混乱之中。
当然，我们一直在努力修正这些问题，情况有了一定的改善 - 虽然 GNOME 2.x 平台的确解决了很多问题，但还是存在一些问题。
对我而言，.NET 就象是为 Win32 开发人员所做的升级：在处理 API 时他们遇到了同样的问题，因为 API 是多年前的设计，存在大量的不一致性。因此，在创建自己的应用程序时，我希望引进一些新的东西。
Dare Obasanjo：Bonobo 不太依赖于 COM 和 OLE2，这可以从 Bonobo 接口基于 Bonobo::Unknown 接口这一事实推出。该接口提供两项基本服务：对象生存期管理和对象功能搜索，并且只包含三种方法。
它们与 Microsoft 的 COM IUnknown 接口的三种方法非常相似。
.NET 似乎暗示了 COM 的终结这一事实，是否也意味着 Mono 将结束 Bonobo 呢？同样，考虑到 .NET 计划实现了半透明的 COM/.NET 互操作性（英文），Mono 和 Bonobo 是否也有类似的计划？
Miguel de Icaza：确实如此。Mono 必须与 GNOME 的 Bonobo 以外的大量系统进行交互操作。
Dare Obasanjo：许多人士声称 Microsoft .NET 平台只不过是 Java™ 平台的蹩脚的克隆。在这种情况下，Ximian 为什么决定不克隆或使用 Java 平台，而克隆 Microsoft .NET 平台？
Miguel de Icaza：因为 CLR 可以解决每天困扰我们的问题，而 Java VM 却不能，所以我们更喜欢 CLR。
Dare Obasanjo：Mono Rationale 页（英文）中指出 Microsoft .NET 策略提供了许多功能：
您还指出 Mono 仅仅是 .NET 开发平台的实现方案，那么 Ximian 是否计划实现 .NET 策略的其他部分？
Miguel de Icaza：目前尚未打算这样做。我们当前要开发的是：
以上目标都需要外界的帮助。要知道这是一个庞大的工程，如果没人愿意无私地奉献他们的时间、技术和代码，那么我们将无法迅速地提供完整的产品。
我们这样做是出于自私的考虑：希望找到更好的方法开发我们自己的 Linux 和 Unix 应用程序，而 CLI 正是我们所需要的。
也就是说，在服务和支持业务上，Ximian 将不吝提供支持，帮助 Mono 项目解决诸如移植到新平台、改善 JIT 引擎或者专注于 Mono 的某一特殊领域等问题。
但是除了这些，目前我们暂不考虑研究三项基本声明以外的项目。
Dare Obasanjo：现在有许多其他项目依靠免费平台实现 .NET 的其他部分，这似乎同 Mono 项目有点冲突。在第 7.2 节的 Portable.NET 常见问题（英文）中，好象是说在 dotGNU 邮件列表中禁止 Martin Coxall，是因为它们与 Mono 项目发生了冲突。对此您有何看法？
Miguel de Icaza：我没有留意 DotGNU 邮件列表中禁止 Martin 的详细情况。Usenet 和 Internet 的邮件列表都体现了它们各自的特点，我认为这也是 Internet 上常见的现象之一吧。不过，出现这种问题确实令人难过。
Mono 和 .NET 只有细微的差别：我们尽可能使用 C# 等高级语言编写程序，而使用其他语言编写可重复使用的软件片段。目前，Portable.NET 是使用 C 语言编写的。
Dare Obasanjo：媒体对于 Ximian 和 Microsoft 的关系的报道也大相径庭，有的报道似乎暗示在保护 .NET 和 GPL 的许可协议之间可能存在许可问题。还有的报道说，Microsoft 内部有些人对 Mono 极为关注。那么，目前 Ximian 与 Microsoft 的关系到底如何呢？应采取何种措施确保当 Microsoft 的许可协议转为有限制时，在 .NET 问题上 Mono 才不会违反 Microsoft 的许可协议？
Miguel de Icaza：好，第一点，我们是从头编写每样东西的。
另外，在专利方面，我们也尽量避免侵权问题的发生。也就是说，我们目前使用的方法都是别人以前使用过的方法。而且对于 Mono，我们尚未做出太细致的工作或者取得很有效的成果，相反我们差得还很远，目前只是使用现有的技术和方法。
Dare Obasanjo：有人指出 Sun 曾经至少两次从标准进程中收回 Java，那么如果不论何种原因，.NET 不再作为开放式标准，您是否仍会继续 Mono 项目？
Miguel de Icaza：不论是否为标准平台，升级我们的开发平台都有其特殊的价值。Microsoft 将自己的规范提交给一个标准化组织的事实可以进一步说明这个道理，因为了解这些问题的人们已经开始考虑这些问题，并且能够从互操作性的角度出发找出问题的原因。
Dare Obasanjo：同样，如果 Dan Kusnetzky 的预言成为事实，而且以后 Microsoft 更改了 .NET API，Mono 项目会怎样做？是跟进，还是成为 UNIX 平台上不兼容的 .NET 实现方案？
Miguel de Icaza：Microsoft 在保持 API 的向后兼容性方面做得非常好，我认为这也是它作为平台供应商取得巨大成功的原因之一，所以我认为这不会成为一个问题。
即便出现了这样的问题，也有多种实现方案可以获得相同的 API 并通过在运行时选取适当的“程序集”来获得正确的方案。程序集是处理软件包和文件（作为程序集的一部分）的一种新方法，并且可以对程序集进行加密校验，以及对它们的 API 进行编程测试，检查它们的兼容性。[[B]Dare[/B] - 有关程序集的详细信息，请参阅 .NET Framework Glossary（英文）。]
因此，即使它们偏离了最初的版本，我们还是有能力提供可兼容低版本的程序集，对于 Microsoft 软件和我们自己的软件都一样。
Dare Obasanjo：在 Mono 类状态页（英文）中，我注意到在 Mono 中有大量的 .NET 类库没有实现，例如 Windows 窗体、ADO.NET、Web 服务、XML 架构、映像以及许多其他类库。这意味着最终发布 Mono 和 .NET 时，为 .NET 编写的程序将很有可能无法移植到 Mono 中。对此，是否打算将来再进行修正，还是说 Mono 项目并没打算创建一个可移植的 .NET 平台？换句话说，也就是 Mono 项目的近期目标和远期目标分别是什么？
Miguel de Icaza：状态 Web 页反映了人们“必须”使用的类，就好象在说“嘿，我现在正在使用这个类”，这样可以避免代码重复。如果有人选择了自己感兴趣的类，而过一段时间后又放弃了，那么我们可以收回这个类。
由于项目刚刚开始，所以您会发现基本类的工作量要远远超过最终用户类的工作量。
出乎意料的是，在项目的起步阶段就吸引了这么多出色的天才编程人员。按照我一开始的预测，要用最初的三个月时间来处理公共关系，以便解决缺少外部合作者的问题，事实证明我错了。
您应该意识到 Mono 项目的目标并不只是 Ximian 的目标。Ximian 有一整套目标，但是每个合作者却有他自己的目标：有人想学习，有人喜欢研究 C#，有人希望在 Linux 上实现 .NET 完全兼容性，有人喜欢语言独立，有人希望优化代码，有人喜欢底层编程，有人希望同 Microsoft 竞争，还有人喜欢 .NET 服务的工作方式。
因此项目的方向掌握在为它付出努力的那些人的手中。许多人对于在非 Windows 平台上实现兼容的 .NET 感兴趣，并且正在朝这一目标努力。
Dare Obasanjo：最近很多依靠风险基金投资、基于免费软件的公司都破产了，例如 Indrema、Eazel 和 Great Bridge，而仅存的基于免费软件的公司中也有相当一部分濒临破产。在这样的情况下，Ximian 是否考虑过如何支付 Mono 的开发费用的问题？另外，Ximian 计划如何利用免费软件赚钱，更具体地说，如何利用 Mono？
Miguel de Icaza: Ximian 准备提供支持和各种服务。最近我们宣布了几个服务项目，而更多的产品和服务已经成形，并且将在未来六个月内发布。
近期发布的服务项目包括：
我们也一直在为整合基于免费软件的解决方案的人士提供专业服务和支持。
Mono 的特殊情况是很有意思的。我们正致力于 Mono 的研究以降低开发成本，已经有一个非常好的基金投入进来，并且已提交给了 ECMA。现在，很多其他团体也认识到了 Mono 的实力，在他们的鼎力相助下，我们正在开发 Mono 运行时和开发工具，以提高生产效率。
事实上，目前 Ximian 中从事 Mono 的团队，正是过去为公司的其他事业奠定基础的团队。
Dare Obasanjo：可能很少有人知道您曾经与 Microsoft 商谈（英文）开发 Internet Explorer SPARC 端口的事情。考虑到目前您在免费软件界的影响，您是否想象过如果当初加入 Microsoft，现在会是怎样一种情况？
Miguel de Icaza：我没有做过多考虑，但我的确曾经向我在 Microsoft 访问的每位人士请求公开 Internet Explorer 源代码，那是在公开 Netscape Communicator 之前。
Dare Obasanjo(kpako@yahoo.com) 是乔治亚理工学院 (Georgia Institute of Technology) 四年级的学生，正在攻读计算机科学工科学士学位。他业余时间在许多网上论坛发布过文章，例如 Slashdot、Kuro5hin 和 Advogato，同时还撰写了许多关于编程和软件的文章。他曾在多家公司实习过，包括 Radiant Systems、i2 Technologies 和 Microsoft。目前他正在准备论文答辩，完成乔治亚理工学院的学业后，他最有可能去 Redmond。
Dare Obasanjo
2001 年 12 月
摘要：在本次访谈中，GNOME 和 Ximian 的创始人 Miguel de Icaza 讨论了 UNIX 组件、Bonobo、Mono 和 Microsoft .NET。
Dare Obasanjo：最近您一直忙于发布 Ximian（英文）的声明，宣布创建 Microsoft .NET 开发平台（英文）的开放源代码版本。此前，您为 GNOME（英文）和 Bonobo 所做的工作使您受到了世人的广泛关注。您能否简单概括一下从早期项目到 Mono（英文），您在免费软件开发方面所作的工作？
Miguel de Icaza：在过去的四年里，我一直从事 GNOME 项目的各个领域的工作，比如：GNOME 项目的组织、程序库和应用程序。此前，我从事 Linux 内核方面的工作：我用了很长时间研究 SPARC 端口；这之后研究了软件 RAID 和 Linux/SGI。之前，我编写了 Midnight Commander 文件管理器。
Dare Obasanjo：在您撰写的 Let\'s Make Unix Not Suck（英文）系列文章中，您曾提到由于缺乏可重复使用的代码致使 UNIX 的开发长期以来受到束缚，您特别强调了 Brad Cox（英文）的“软件集成电路”概念，指出软件构建主要基于组合可重复使用的组件，也就是要编写可以重复使用的代码。许多人反对您的观点，他们认为 UNIX 的建立基础，是通过使用管道连接较小程序的输出，来使用可重复使用的组件完成程序构建。您对这一反对观点有何看法？
Miguel de Icaza：是的，这个问题已经详细刊登出来了。这里提到的“管道”严格说不能作为完整的组件系统。它只是一种使用某些常用协议（例如行、字符、缓冲区等）处理信息的传输机制。而协议只拥有信息流。
详细内容都刊登在那篇文章（英文）中。[[B]Dare[/B] - 请参阅“Unix Components: Small is Beautiful”。]
Dare Obasanjo：Bonobo 是您尝试以 CORBA 为基础来创建 UNIX 组件体系的产品，后来为何又转而开发 Mono 呢？
Miguel de Icaza：GNOME 项目的目标是补充 Unix 所缺少的技术，从而在桌面应用程序市场中更具竞争力。我们很早就意识到语言独立性的重要性，这也是 GNOME API 使用标准代码进行构建的原因。这种标准代码使得 API 可以被其他语言轻松打包。Unix 的大多数编程语言（例如 Perl、Python、Scheme、C++、Objective-C、Ada）都可以使用我们的 API。
后来，我们决定使用更好的方法来封装 API，于是就开始使用 CORBA 来定义组件的接口。我们还使用策略和一套标准 GNOME 接口对其进行补充，以便更轻松地创建可重复使用的、独立于语言的组件、控件和复合文档。这项技术就是今天的 Bonobo。C、Perl、Python 和 Java 都可以使用 Bonobo 的接口。
CORBA 擅长定义粗糙接口，而且大多数的 Bonobo 接口都是粗糙的。唯一的问题是 Bonobo/CORBA 接口都不善于定义小接口。例如，XML 分析 Bonobo/CORBA 组件可能没有 C API 有效。
以前我也论述过：
我对 .NET 的兴趣源于我们先前在 GNOME 项目中所做的努力，我们曾尝试使 .NET 能够完成以下目标：
- 可以向多种语言提供的 API
- 跨语言集成
- 基于合约/接口进行编程
当然除此以外，我一直钟爱各种有关 Java 的事情，只是不愿让 Java 组合有一丝缺陷。
我们尝试通过配备公共对象基类 (GtkObject) 在多种语言中提供 API，然后根据 API 约定和格式轻松地对 API 进行打包，以用于其自身的编程语言。我们还对 API 进行基于方案的定义，用它自由生成包装。鉴于多种原因，这个解决方案还是有些欠佳。
对 CORBA 进行的跨语言集成有些类似于 COM，但是要付出一些封送处理的代价。它可以很好地处理非进程组件，但是对于进程组件，情况就不那么美妙了：因为没有可用的 CORBA ABI，所以结果糟透了。对于这个问题，我不想多说什么。
此外，我们还遇到了程序库的扩大问题。大多数程序库都能非常准确地遵循代码惯例，但偶尔也会违反惯例，或者我们采用了其他人编写的程序库，却导致了程序库的混乱：虽然功能强大，但实现了多个编程模式。有时是不同的分配和所有权策略，有时又要处理 5 个不同种类的“ref/unref”行为（例如 CORBA 本地引用、关于未知对象的 CORBA 对象引用、对象包装的引用计数）。这使我们陷入了巨大的混乱之中。
当然，我们一直在努力修正这些问题，情况有了一定的改善 - 虽然 GNOME 2.x 平台的确解决了很多问题，但还是存在一些问题。
对我而言，.NET 就象是为 Win32 开发人员所做的升级：在处理 API 时他们遇到了同样的问题，因为 API 是多年前的设计，存在大量的不一致性。因此，在创建自己的应用程序时，我希望引进一些新的东西。
Dare Obasanjo：Bonobo 不太依赖于 COM 和 OLE2，这可以从 Bonobo 接口基于 Bonobo::Unknown 接口这一事实推出。该接口提供两项基本服务：对象生存期管理和对象功能搜索，并且只包含三种方法。
module Bonobo { interface Unknown { void ref (); void unref (); Object query_interface (in string repoid); }; };
它们与 Microsoft 的 COM IUnknown 接口的三种方法非常相似。
HRESULT QueryInterface(REFIID riid, void **ppvObject);ULONG AddRef();ULONG Release();
.NET 似乎暗示了 COM 的终结这一事实，是否也意味着 Mono 将结束 Bonobo 呢？同样，考虑到 .NET 计划实现了半透明的 COM/.NET 互操作性（英文），Mono 和 Bonobo 是否也有类似的计划？
Miguel de Icaza：确实如此。Mono 必须与 GNOME 的 Bonobo 以外的大量系统进行交互操作。
Dare Obasanjo：许多人士声称 Microsoft .NET 平台只不过是 Java™ 平台的蹩脚的克隆。在这种情况下，Ximian 为什么决定不克隆或使用 Java 平台，而克隆 Microsoft .NET 平台？
Miguel de Icaza：因为 CLR 可以解决每天困扰我们的问题，而 Java VM 却不能，所以我们更喜欢 CLR。
Dare Obasanjo：Mono Rationale 页（英文）中指出 Microsoft .NET 策略提供了许多功能：
- .NET 开发平台，软件编写的新平台
- Web 服务
- Microsoft 服务器应用程序
- 使用新开发平台的新工具
- Hailstorm，作为以 Microsoft .NET Passport 为中心的单一登录系统，集成到 Microsoft Windows XP 中。
您还指出 Mono 仅仅是 .NET 开发平台的实现方案，那么 Ximian 是否计划实现 .NET 策略的其他部分？
Miguel de Icaza：目前尚未打算这样做。我们当前要开发的是：
- CLI 运行时，带有适用于 x86 CPU 的 JITer
- C# 编译器
- 类库
以上目标都需要外界的帮助。要知道这是一个庞大的工程，如果没人愿意无私地奉献他们的时间、技术和代码，那么我们将无法迅速地提供完整的产品。
我们这样做是出于自私的考虑：希望找到更好的方法开发我们自己的 Linux 和 Unix 应用程序，而 CLI 正是我们所需要的。
也就是说，在服务和支持业务上，Ximian 将不吝提供支持，帮助 Mono 项目解决诸如移植到新平台、改善 JIT 引擎或者专注于 Mono 的某一特殊领域等问题。
但是除了这些，目前我们暂不考虑研究三项基本声明以外的项目。
Dare Obasanjo：现在有许多其他项目依靠免费平台实现 .NET 的其他部分，这似乎同 Mono 项目有点冲突。在第 7.2 节的 Portable.NET 常见问题（英文）中，好象是说在 dotGNU 邮件列表中禁止 Martin Coxall，是因为它们与 Mono 项目发生了冲突。对此您有何看法？
Miguel de Icaza：我没有留意 DotGNU 邮件列表中禁止 Martin 的详细情况。Usenet 和 Internet 的邮件列表都体现了它们各自的特点，我认为这也是 Internet 上常见的现象之一吧。不过，出现这种问题确实令人难过。
Mono 和 .NET 只有细微的差别：我们尽可能使用 C# 等高级语言编写程序，而使用其他语言编写可重复使用的软件片段。目前，Portable.NET 是使用 C 语言编写的。
Dare Obasanjo：媒体对于 Ximian 和 Microsoft 的关系的报道也大相径庭，有的报道似乎暗示在保护 .NET 和 GPL 的许可协议之间可能存在许可问题。还有的报道说，Microsoft 内部有些人对 Mono 极为关注。那么，目前 Ximian 与 Microsoft 的关系到底如何呢？应采取何种措施确保当 Microsoft 的许可协议转为有限制时，在 .NET 问题上 Mono 才不会违反 Microsoft 的许可协议？
Miguel de Icaza：好，第一点，我们是从头编写每样东西的。
另外，在专利方面，我们也尽量避免侵权问题的发生。也就是说，我们目前使用的方法都是别人以前使用过的方法。而且对于 Mono，我们尚未做出太细致的工作或者取得很有效的成果，相反我们差得还很远，目前只是使用现有的技术和方法。
Dare Obasanjo：有人指出 Sun 曾经至少两次从标准进程中收回 Java，那么如果不论何种原因，.NET 不再作为开放式标准，您是否仍会继续 Mono 项目？
Miguel de Icaza：不论是否为标准平台，升级我们的开发平台都有其特殊的价值。Microsoft 将自己的规范提交给一个标准化组织的事实可以进一步说明这个道理，因为了解这些问题的人们已经开始考虑这些问题，并且能够从互操作性的角度出发找出问题的原因。
Dare Obasanjo：同样，如果 Dan Kusnetzky 的预言成为事实，而且以后 Microsoft 更改了 .NET API，Mono 项目会怎样做？是跟进，还是成为 UNIX 平台上不兼容的 .NET 实现方案？
Miguel de Icaza：Microsoft 在保持 API 的向后兼容性方面做得非常好，我认为这也是它作为平台供应商取得巨大成功的原因之一，所以我认为这不会成为一个问题。
即便出现了这样的问题，也有多种实现方案可以获得相同的 API 并通过在运行时选取适当的“程序集”来获得正确的方案。程序集是处理软件包和文件（作为程序集的一部分）的一种新方法，并且可以对程序集进行加密校验，以及对它们的 API 进行编程测试，检查它们的兼容性。[[B]Dare[/B] - 有关程序集的详细信息，请参阅 .NET Framework Glossary（英文）。]
因此，即使它们偏离了最初的版本，我们还是有能力提供可兼容低版本的程序集，对于 Microsoft 软件和我们自己的软件都一样。
Dare Obasanjo：在 Mono 类状态页（英文）中，我注意到在 Mono 中有大量的 .NET 类库没有实现，例如 Windows 窗体、ADO.NET、Web 服务、XML 架构、映像以及许多其他类库。这意味着最终发布 Mono 和 .NET 时，为 .NET 编写的程序将很有可能无法移植到 Mono 中。对此，是否打算将来再进行修正，还是说 Mono 项目并没打算创建一个可移植的 .NET 平台？换句话说，也就是 Mono 项目的近期目标和远期目标分别是什么？
Miguel de Icaza：状态 Web 页反映了人们“必须”使用的类，就好象在说“嘿，我现在正在使用这个类”，这样可以避免代码重复。如果有人选择了自己感兴趣的类，而过一段时间后又放弃了，那么我们可以收回这个类。
由于项目刚刚开始，所以您会发现基本类的工作量要远远超过最终用户类的工作量。
出乎意料的是，在项目的起步阶段就吸引了这么多出色的天才编程人员。按照我一开始的预测，要用最初的三个月时间来处理公共关系，以便解决缺少外部合作者的问题，事实证明我错了。
您应该意识到 Mono 项目的目标并不只是 Ximian 的目标。Ximian 有一整套目标，但是每个合作者却有他自己的目标：有人想学习，有人喜欢研究 C#，有人希望在 Linux 上实现 .NET 完全兼容性，有人喜欢语言独立，有人希望优化代码，有人喜欢底层编程，有人希望同 Microsoft 竞争，还有人喜欢 .NET 服务的工作方式。
因此项目的方向掌握在为它付出努力的那些人的手中。许多人对于在非 Windows 平台上实现兼容的 .NET 感兴趣，并且正在朝这一目标努力。
Dare Obasanjo：最近很多依靠风险基金投资、基于免费软件的公司都破产了，例如 Indrema、Eazel 和 Great Bridge，而仅存的基于免费软件的公司中也有相当一部分濒临破产。在这样的情况下，Ximian 是否考虑过如何支付 Mono 的开发费用的问题？另外，Ximian 计划如何利用免费软件赚钱，更具体地说，如何利用 Mono？
Miguel de Icaza: Ximian 准备提供支持和各种服务。最近我们宣布了几个服务项目，而更多的产品和服务已经成形，并且将在未来六个月内发布。
近期发布的服务项目包括：
- Red Carpet Express：一种订阅服务，提供对 Red Carpet 服务器的可靠、快速的访问。
- Red Carpet Corporate Connect：我们修改了 Red Carpet 的更新技术，帮助人们轻松管理 Linux 网络工作站，轻松部署和维护自定义软件包。
- 对 GNOME 桌面和 Evolution 提供支持和服务：最近的一系列产品都体现了我们“为多种产品提供支持服务”这一思想。
我们也一直在为整合基于免费软件的解决方案的人士提供专业服务和支持。
Mono 的特殊情况是很有意思的。我们正致力于 Mono 的研究以降低开发成本，已经有一个非常好的基金投入进来，并且已提交给了 ECMA。现在，很多其他团体也认识到了 Mono 的实力，在他们的鼎力相助下，我们正在开发 Mono 运行时和开发工具，以提高生产效率。
事实上，目前 Ximian 中从事 Mono 的团队，正是过去为公司的其他事业奠定基础的团队。
Dare Obasanjo：可能很少有人知道您曾经与 Microsoft 商谈（英文）开发 Internet Explorer SPARC 端口的事情。考虑到目前您在免费软件界的影响，您是否想象过如果当初加入 Microsoft，现在会是怎样一种情况？
Miguel de Icaza：我没有做过多考虑，但我的确曾经向我在 Microsoft 访问的每位人士请求公开 Internet Explorer 源代码，那是在公开 Netscape Communicator 之前。
Dare Obasanjo(kpako@yahoo.com) 是乔治亚理工学院 (Georgia Institute of Technology) 四年级的学生，正在攻读计算机科学工科学士学位。他业余时间在许多网上论坛发布过文章，例如 Slashdot、Kuro5hin 和 Advogato，同时还撰写了许多关于编程和软件的文章。他曾在多家公司实习过，包括 Radiant Systems、i2 Technologies 和 Microsoft。目前他正在准备论文答辩，完成乔治亚理工学院的学业后，他最有可能去 Redmond。
