TrixX's Journal: A soothing light at the end of the tunnel

Four months have gone since my last post here. In that last post, I mentioned about several political issues that were going around the Eiffel language standarization and its implementations.

There have been some little but interesting movements in that story. ECMA-367, the new Eiffel standard. Came out in June, making a slight blip on some radars but not much more. The standard includes some inconsistencies (some problems with non-conforming inheritance I mentioned before, and some changes in notation to avoid special-cases, which don't solve the problem but still cause incompatibilities).

Meanwhile, the SmartEiffel team declared that ECMA was forking Eiffel (which, from some point of view, is true), and they were going to keep developing an implementation of the "true Eiffel language" (which is, from some points of view, quite pretentious....).

As I said before I believed that the only way to move forward, would be having a Libre (Free as in speech) Eiffel compiler capable of forming a community around it. Visual Eiffel was too small, and SmartEiffel looked quite closed as a community. As an implementation, SmartEiffel had almost everything that was needed. The only problem remaining were the incompatibilities between the 1.x releases and the new 2.x, that made porting old software and reusing quite difficult.

On May 10th, a week after my previous post here, I emailed the members of the SmartEiffel team. I offered them to work in a "sequel" to the 1.1 compiler, a compiler from the 1.x series that would be 100% 1.1 compatible, but would introduce several changes to ease migration into SmartEiffel 2.x. That could help the community unifying into a single SE version (the 2.x branch), and being able to reuse old software, and/or port it easily.

The answer was much more open that what I had thought (I was thinking they would be reticent to have a SE fork around). They were quite happy about it, and made me feel more comfortable about branching (I could have just forked without their authorization, being GPL code, but didn't want to split the already small community). My work was going to be a "branch" instead of a "fork" (just because "branch" sounds more friendly), be developed independently, and would be called "SmartEiffel 1.2 (transitional)".

I quickly started setting things up. I found the free hosting at OpenSVN.csie.org, which is great (free SVN and Trac, a free integrated wiki+svn browser+issue tracker that we're also using at except). I set up my site there, at https://opensvn.csie.org/traccgi/smarteiffel12. On May 25th, I made a public announcement about the project at the SmartEiffel mailing list. My plan was to go on with 1.1 development at my site, with my own rules (an open repository, open development mailing list, open wiki)

Meanwhile, the SmartEiffel team started making some nice movements toward openness. They invited me to the developer team (which includes subscribing to the private developer mailing list and access to the CVS repository) so I could participate and have access to revision history that would be useful for deveolping my branch. I joined having doubts about forming part of a closed process. But there I knew that they were also planning to get open to the community, creating a public developer list, and putting a wiki online.

I finished setting up everything that was needed for development during June, and made a release (1.2r0) on July 1st. That release was essentially a "rebranded" 1.1. Some days later, on July 6th, The SmartEiffel wiki went also online. And for days later, the expected new gobo 3.4 was released. On July 23rd the open SmartEiffel development list was announced. So July brought several good news and fresh air to Eiffel developers in the free software community.

Things seems little better now in the horizon. Nobody has cared much about ECMA (with no implementations in sight). The SmartEiffel guys are improving their development process in an open-source-frindly way. SmartEiffel 2.x as a language is stabilizing and getting cleaner (2.2 is even accepting some extra things for backward compatibility that 2.0 and 2.1 didn't). 1.2 keeps improving (2 releases since) and getting more compatible with 2.2 without being less 1.1 compatible, and adding some compatibility with other compilers.

An officially accepted Eiffel standard would be a nice addition, but I don't see one coming soon. A second best can be a defacto open-source standard (that seems to work wll for things like Python or PHP). I now see SmartEiffel able to get there; there is still some way to go. Wish us luck.