On Fri, Aug 9, 2013 at 4:18 PM, Diederik van Liere
<dvanliere(a)wikimedia.org>wrote;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.