Zach Beane (xach) wrote,

ECL needs a maintainer

Juanjo sent en email yesterday about about the status of ECL:

* First of all, ECL no longer relates to my own work. On the contrary, other open source projects that I carry on (https://github.com/juanjosegarciaripoll?tab=repositories) are more directly related to my research and are demanded by my group. This is detracting development time from the project, but there is little I can do, as that numerical software is what feeds our bellies right now.

* Not only does my work consume most of my open-software development time, but the job overall does significantly constraint the time I can spare for the project. As group leader in a research environment with scarce resources, I spend more time writing grant applications and bureaucracy than I do in front of Emacs. Quite frustrating as it is, I only see it worsening in the near future.

* The consequence is that the time I can devote to ECL has serious ups and downs. In an environment of rapidly developing tools and libraries, this is quite unfortunate, as the project may lag behind and become obsolete. This is indeed what has happened with several of the ports out there.

* On top of this, there are a lot of frustrating things that I did not want to care about but which are bugging me right now and also stealing time. The first one is the license issue. I put out a suggestion to migrate to MPIR because I knew that MPIR had an effort to stay with LGPL2. Regrettably, I did not know that this effort was abandoned so that if ECL wishes to upgrade to any more recent version of GMP/MPIR it has to migrate to LGPL3.

* Another nagging issue is testing. You have suffered this in the past and it still is a problem: my testing environment is broken and I do not have time to fix it. Despite Anton's wonderful library, the fact is that it is a heck of a problem to maintain several virtual machines and computers in an uncooperative computing environment with frequent blackouts.

* Finally, on the one hand, there are many new upcoming implementations out there, some with promising results and features that I do not have the time to incorporate -- but which would be simple with resources -- and certain forks are consolidating. On the other hand, despite ten years of development, I have failed to aggregate any number of contributing developers around this project. This may be blamed on the community or on myself, and it does not match the supportive and helpful user base that ECL has always had, but the fact is that it is a problem and a time has come to accept it [but please, I do not need your pity on the IRC channels, ok?]

Though I did not have time to develop, I had time to think, even if on the bus trips and planes, and I came to the following conclusions:

* I am resigning and opening the position of ECL maintainer for anyone to take. I will grant him or her with full administrative rights and full responsibility over the project's future. No need to fork the project: if you really feel you can make it better, step ahead and take it. I will remain as a support developer and help you as much as I can.

* If no one takes over maintenance, I will continue working as I can, when I can. This may be unsatisfactory for many of you -- if this is the case, I am sorry, but that's all there is.

Read the whole thing.

Tags: lisp
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded  

  • 0 comments