[vtk-developers] Driving away your existing developers

Wed Aug 27 17:03:55 EDT 2014

I would love to see more of your excellent work, David, and I'd want to
make use of it, but I'd argue that at least some of it, perhaps
registration, may not belong in VTK itself.

Speaking for myself from my experience in the slicer project, I can say
that we end up putting a lot of our functionality in classes that don't
belong back into VTK proper, such as vtkITK, vtkTeem, and vtkMRML, each of
which adds functionality that is independent of our slicer application, but
adds a layer of dependencies that nobody would want to see in VTK itself.

On my wishlist for VTK would be a better way for new developers to
contribute their work so that it's easily usable by others but doesn't have
to pass the gauntlet of reviews and comments and be in VTK before it is
easily usable by others.  I'd like to see an experience more like npm for
node, where anyone can publish a domain-specific set of code and other
people can use it or not as they see fit.  Node itself remains small and it
rarely changes, but the ecosystem is quite vibrant.  It allows a lot of
diversity, but amazing interoperability and reusability.

In slicer we have something similar now with the Extension Catalog, where
developers can offer code (either pure VTK or things that work at the
VTK/ITK/Qt/Slicer level) that is optionally installed.  Since we perform
nightly builds and test it on all platforms, this code is in reasonable
shape for other people to draw from, either in slicer or elsewhere.
 Typically these extensions are in github repositories, so they have their
own wikis, issue lists, pull requests, etc.  We hope that slicer itself
actually gets smaller over time and generally doesn't need to change very
much or very often.

I would love to see something similar in VTK proper.  Right now VTK has a
lot of modules that are quite domain specific, such as Chemistry and Geovis
which I do not envision using myself.  I would have preferred to see that
code exist in a different repository where people who needed it would have
the option of including it in their superbuild process.  Others could
safely ignore it.  I would even argue that half (or more) of the current
modules don't really belong in the 'actual' VTK and should be moved out.
 If there were a good place to put some of this kind of code it might also
be a good spot for libraries like vtkITK and vtkTeem.  In fact I would
argue that if it weren't actually in VTK's repository, a project like
vtkChemistry might attract more participants and have more features (but I
can't prove that of course).

So basically I'd say that VTK is currently too big and should get smaller,
while the community is too small and should get bigger.

-Steve

On Wed, Aug 27, 2014 at 12:00 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> On Wed, Aug 27, 2014 at 7:10 AM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
> > One final note. Everyone please keep in mind that while there are quite a
> > lot of contributors to VTK, certain parts of it are developed by only a
> few
> > people. Core pipeline: I am it at this point. Rendering: by next year, it
> > will be Ken and Marcus. Imaging: hardly anyone in the scientific vis
> team at
> > Kitware does anything with imaging filters. We update them when we make
> > changes to the pipeline or data model but that's it. So some of those are
> > maintained and developed by others or they are some orphaned. This can
> only
> > be addressed by either encouraging new (or existing) developers to take
> > ownership or by removing those components all together.
>
> I have tons of plans for the VTK imaging classes, but unfortunately I have
> almost no resources so progress is slow.  Some examples:
>
> 1) Improving both the API and the performance for multi-threading.
> Last year I worked with an intern to improve load sharing.  Never had
> time to finish, because it wasn't the intern's main project.
>
> 2) Basic linear image registration in VTK.  I've finished it and it's
> very robust (been using it for years), but refactoring so that it can
> be contributed to VTK is an evening/weekend project and hence is
> moving slowly.
>
> 3) Better image iterators.  I have a nice image iterator that iterates
> over arbitrary shapes and also provides coordinate info while it
> iterates.  I'd love to develop this further and contribute it, and I'd
> especially love to wrap it, but it's out in left field as far as my
> day job goes.
>
> 4) Better filters for going back and forth between image data and
> polydata.  Lots of people use my vtkPolyDataToImageStencil filter,
> but it has faults and I know exactly how to fix them, but I'll have to
> wait until it comes up as a priority for one of my work projects.
>
> 5) Finally, a better overall structure for the imaging pipeline,
> focused on the basics:
>  a) scalar operation "functors" that can be plugged into filters
>  b) interpolators, which I've already committed
>  c) good image "region" descriptors (like my vtkImageStencilData)
>  d) connectivity & morphological operations, I've got lots of un-committed
> stuff
>  e) a replacement for the lousy vtkImageMathematics filter
>
> Ideally I should write out a big roadmap (the items mentioned above
> is just a fraction of the total), but it would be depressing because so
> much of it feels like it's nothing more than a pipe dream.
>
> And, as Berk mentioned, there isn't anyone in Kitware for me to
> directly work with on this stuff.  And all the other VTK imaging
> developers outside of Kitware are content to keep their work to
> themselves, without contributing back to the VTK core.  Or at least,
> that's the way it looks from my vantage point.
>
>  - David
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140827/1d99ddef/attachment-0002.html>