On Fri, Aug 9, 2013 at 4:18 PM, Diederik van Liere <dvanliere@wikimedia.org> wrote:

I have been talking with a lot of you in the past months and at Wikimania about Limn and how to move forward. One of the recurring themes has been that currently Limn is written in Coca and that significantly hinders adoption as there are very few Coco developers (Coco is a fork of Coffeescript).

Limn needs two things to survive: users that like using it and developers that like developing it. You have the users. You need developers. Limn is not realistically going to attract substantial contributions from volunteers in the open source community, so you need to hire someone for the role. The job market for Coco developers is comparable in size and ontic status to the job market for tooth fairies, so you will need to hire a JavaScript developer, and you need to find a way to keep her or him motivated. The best way to do that is to tell this developer that you respect her intuitions and judgments and are trusting her to make the right call re: Coco vs. JavaScript and other matters related to software architecture. The specifications you provide should be expressed in terms of user requirements.

I would not attach too much significance to the choice of Coco vs. JavaScript. The choice of Coco drew so much ire not by dint of any feature of the language itself, but because the choice epitomized an approach to development that focused on self-gratification and posturing rather than simplicity and practicality. Dan's heroic efforts to clean it up have improved things considerably, but in my estimation Limn is not going to survive, because there are very few talented developers out there who are enticed by the prospect of cleaning up other people's mistakes as a full-time job.

It is important to realize that most of the functionality that users attribute to Limn is actually provided by external libraries (point in fact: vendor-bundle.min.js is 411k, limn.no-deps.min.js is 254k). I don't think that there is enough in that 254k to justify a substantial investment of resources.

In my opinion, the most sensible course forward is to feature-freeze Limn, hire a good, creative JavaScript developer with experience in data visualization, and commit 20% of this developer's time to Coco maintenance. The primarily purpose of this 20% time is to provide a context for the developer to interact with users and to understand what they like and what their wishes are. Anything beyond this 20% should decidedly not be encumbered by an indefensible a priori decision that Limn will be the visualization framework of the future.