Re: Volunteering to maintain ob-asymptote.el within Org

[Tim Cross <theophilusx@gmail.com>]

Ihor Radchenko <yantar92@gmail.com> writes:

> Another question is long-term maintainability. We have a limited
> manpower and cannot cater too many support requests or take care about
> parts of code not used by most people. After removing org-contrib over a
> year ago, your email is the first issue raised regarding ob-asymptote
> removal. Since you are volunteering to maintain it, things gets easier.
> However, the final decision is after Bastien.
>

and I don't think it is a decision which has to be made now.

It is fantastic someone has stepped up to maintain this code. However,
it may be wise to wait 12 months before making an important decision
like moving it into core. While moving something into core may seem
easy, moving it back out tends to be more problematic and require more
change management to avoid unexpected impact to org users (including
none users of this module who could also be impacted by any breakage
introduced).

As this module has never been part of org core, there is considerable
work which would need to be done as a prerequisite e.g. updating the
manual and adding documentation and examples, adding unit tests
etc. Therefore, I don't think there is any need to make a decision on
this now.

I also think it is prudent to allow any new maintainer some period of
time to get to grips with the maintenance role. Once something becomes
part of core, maintenance demands can increase significantly. For
example, any significant change in org mode or Emacs will need to be
addressed in a timely manner to prevent issues with ob-asymptote
impacting org usage generally. From a maintainers perspective, it often
means having to run multiple versions of both Emacs and org mode,
keeping an eye on org and Eamcs bug reports and responding to user
queries.

In addition to all of this, there is also the unexpected burden of
success. If you actually do a good job, the amount of maintenance work
can actually increase. I speak from personal experience. I took over
maintenance of a small nodejs module about 5 years ago. At the time,
this module had only a few thousand downloads per week. It now averages
around 225k weekly downloads. Code maintenance has not been a
problem. However, user maintenance has been a considerable burden. I
have ended up spending far more time writing documentation, providing
usage examples and helping users than I expected. I would estimate over
80% of all the issues raised by users are due to errors in user code
(most have nothing to do with my module, but I still need to
investigate to verify that). What makes matters harder is that the
module concerned is not one I need any longer. At some point, I will
likely hand maintenance on (assuming someone wants it of course). The
thing to note is that the level of expected maintenance and actual
maintenance can be surprisingly different and it doesn't take much
before that role can become a burden, especially if you have other
demanding work needing attention.  

Finally, we don't actually know what the user base size for asymptote
currently is or could be. I've used org for many years and I've used
plantuml, ditta, graphviz and gnuplot, but I've never used
ob-asymptote. While this may appear to be a critical tool in some use
case groups, it may not be an overall critical module for the overall
org user base. I'm also not convinced that being in contrib rather than
core is really an impediment as suggested. Now that org-contrib is part
of non-gnu ELPA and that archive is automatically configured in new
versions of Emacs, adding org-contrib is fairly trivial. I suspect many
users already add it as part of their setup anyway.

While personally I don't agree with adding more things into core, my
main point is we don't need to make this decision now. We can wait 12
months and if whoever is maintaining the mode still wants to see it
moved into core and if all the prerequisite work has been completed, we
can then put it to the community and see what the overall consensus
is. In the meantime, the mode maintainer can work on building the use
base and strengthening their case for inclusion and getting a real feel
for what the maintenance demands are.