[vtk-developers] development roadmap?

[Michael Halle]

I have a question/comment about the vtk development process,
mostly for the Kitware folks.  At Brigham and Women's, we're
trying to move Slicer, our 3D medical visualization platform,
from vtk3.2 to vtk4.  With the people we have (and a ringer like
Bill Lorensen helping out :) I'm sure it will be mostly an
afternoon of intense work.

Our biggest problem is not vtk4, it's which vtk4.  The "extreme
programming" model of develop means that every release should be
a working release: that's great for software quality but not
always so great for planning external software development.
Maybe I missed it, but I don't think there's been an official
release announcement of 4.0.  The online documentation refers to
4.1.1.  Major changes to how people should write modules (the
macro-ization of the New() method, for instance) have occurred
since 4.0.  It's a wonderfully dizzying pace, but it makes
keeping up with it and encorporating new functionality extremely
difficult from the outside.  This note is a desparate plea for
you to clarify your release roadmap so that people who depend on
your work can plan and synchronize our work.

Here's one specific problem we face.  We really want to move to
the out-of-tree development / dynamically loaded module concept
for our C++ functionality.  We've hacked it for vtk3.2, and
prototyped it for vtk4.  Because of the fragile base class
problem, however, we have to version match derived module classes
to the underlying library.  If we want to foster our own software
community at both a module and source code level, we have to
settle on a common version of vtk and advance it in discrete and
relatively large steps (probably when minor numbers are
released).

In the current continuum of VTK development, that's not possible.
Dashboard aside, we can't from the outside determine whether a
particular day is a good day to set a checkpoint.  You might be
adding a very useful structural feature that will both help us
and change how we should be writing code the next day.  We could
react to that, but it seems like wasted effort.  We also can't
point other people to the kitware site and say, "download nightly
from xxxxx."  As developers and collaborators, we simply need
more structure than that.

A map of where you think you're going over, say, the next six
months to a year would be incredibly helpful to us.  Here are
some individual items that we and I think the developer community
at large would enjoy, and from which vtk would benefit.  I'm sure
you've thought about these items: I just want to get them onto
bits so that we can talk about them.

* a roadmap of the changes that will or should be included in the
  next few minor releases as they are known.  The most important
  issues are ones related to "how do I write a module correctly
  for vtk" and "what major underlying features can I expect to
  have available that I don't today."

* clear indication about the current release vtk on the web site
  and documentation.

* regular releases and clear and visible release announcements.

* enforcement of short code freezes and development moratoriums.
  Even the nightlies need more stability from a module writers
  point of view.  Case in point, a module written to vtk4 release
  is now not correct style in the nightly because of the New()
  issue.  The change is good and the work has to be done
  sometime, but as a developer I think it's reasonable to ask
  that there be some limited span of time that particular part of
  vtk doesn't change.  Defined releases are one aspect of the
  solution; enforced discipline and planning is another.
  
* more thought to limited backward compatibility in compilation.
  I believe it currently impossible to write a module that
  conditional compiles for vtk3.2, vtk4, and vtk4-nightly.  If
  the C++ compilation succeeds, the wrapping fails.  I agree that
  vtk itself probably shouldn't be this way internally, but it
  should be possible to write this kind of compatible code with
  effort.

I have no desire to stifle the innovation or growth of vtk.  I am
very also sensitive to the costs of development.  But at this
point, the non-discretized and un-roadmapped (at least to the
outside world) development of vtk is keeping us from using it to
its fullest, which in turn limits how much we can contribute back
to it.  We want to be, and I think we have been, good
contributors to vtk in the open source tradition.  Can you help
us help you?

Thanks.

Michael Halle
Surgical Planning Lab
Brigham and Women's Hospital
mhalle at bwh.harvard.edu