Team Eiffel

The recent SmartEiffel fracas highlighted a situation that's been developing for more than a decade. The Eiffel community has several open source compilers, but does not yet have an open compiler.

The open-sourcing of EiffelStudio has provided an abundance of goodies to Eiffel developers, but the product directions of EiffelStudio are not set by the users of the open source edition. Naturally, the product directions are set by the need of ISE to service their commercial customers, and by the needs imposed by the use of EiffelStudio at ETH.

Similarly, the development of SmartEiffel is driven by the goals of Dominique and his team, and it's pretty clear that those goals often differ from those of the SmartEiffel users.

Visual Eiffel has been open source for a while too, yet it has a provision that patches cannot be accepted into the trunk unless they are also suitable for the proprietary edition.

A truly open Eiffel compiler, with an open development process controlled by its users, would offer many advantages. Foremost of these is that users would discover that it's actually worth their time to contribute - patches will be accepted if considered useful by the users as a whole. This creates a positive feedback loop whereby more people contribute, the product gets better, more people use the product, and even more people contribute.

Another advantage is that open projects tend to emphasize interoperability. To paraphrase something I found at rosegardenmusic.com:

Because of the spirit of openness and co-operation, there's an incentive for people working on quite different applications, libraries and tools to make them work together so as to strengthen all of the pieces.

This is quite unlike the situation we have now where each compiler has its own language and tools, and refuses to support the others.

Stay tuned...