DDF sustainability

[Aaron Hoffer]

Yesterday I wrote down something that has been on my mind, and I would like to share it with the DDF dev community.

Over the past several years, the number of DDF contributors and committers has grown tremendously. That's exciting for the future of DDF, and the other products that build on top of it. When a program responds to the needs of its users by adding features, DDF benefits. Everyone gets to share the new functionality and that is good.

However, new functionality is not entirely free. It is iteratively reviewed, tested on multiple platforms, continuously scanned for CVEs, and carried from one version of Java to the next. New code also adds complexity to an already complex code base. I am concerned that the practice of pushing features and plugins directly into a product’s lowest common denominator – DDF – is ultimately unsustainable.

DDF is managed by the Codice Foundation. The Foundation exercises little governance over its portfolio. It publishes no roadmaps and no criteria for what should be included. That means DDF contributors and committers have to be responsible for its governance. Without that governance, DDF would become a dumping ground for code.

I would like to suggest a more sustainable practice. Extensions and enhancements can be piloted in downstream programs. Incubate the new features outside of DDF. Work out the kinks. Refine the functionality. Remove the technical debt. Let the feature stabilize. Then contribute it to the back.

I hope this provides food for thought and does not engender any acrimony. My observations and suggestions are my own and are motivated by a desire for a great code base for everyone to share.