We need a new S/W dev term Maintenance Debt.
Searching for this, the term shows it only crops up in the phrase Child Maintenance Debt -we need it for software.
Maintenance Debt: the Technical Debt a project takes on when they fork an OSS project.
All OSS code offers you the freedom to make a fork of the code; the right to make your own decisions as to the direction of the code. Git makes that branching a one line action
git branch -c myfork.
Once you fork, have taken on the Maintenance Debt of that fork. You now have to:
- Build that code against the dependencies of your choice.
- Regression test that release.
- Decide which contributions to the main branch are worth cherry-picking into your fork.
- If you do want to cherry pick, adapting those patches to your fork. The more you change your fork, the
more the cost of adaptation.
- Features you add to your branch which you don't contribute back become yours to maintain forever.
- If the OSS code adds a similar feature to yours, you are faced with the choice of adapt or ignore. Ignore it and your branch is likely to diverge fast and cherry-picking off the main branch becomes near-impossible.
- Don't fork.
- Try and get others to add the features for you into the OSS releases.
- As people add the features/fixes you desire, provide feedback on that process.
- Contribute tests to the project to act as regression tests on the behaviours you need. This is a good one as with the tests inside a project, their patch and jenkins builds will catch the problem early, rather than you finding them later.
- If you do write code, fixed and features, work to get them in. It's not free; all of us have to put in time and effort to get patches in, but you do gain in the long term.
- Set up your Jenkins/CI system so that you can do builds against nightly releases of the OSS projects you depend on (Hadoop publishes snapshots of branch 2 and trunk for this). Then complain when things break.
- Test beta releases of your dependencies, and the release candidates, and complain when things break. If you wait until the x.0 releases, the time to get a fix out is a lot longer —or worse, someone can declare that a feature is now "fixed" and cannot be reverted.
If you look at that list, testing crops up a lot. That's because compile and test runs are how you find out regressions. Even if you offload the maintenance debt to others, validating that their work meets your needs is a key thing to automate.
Get your regression testing in early.
[photo: looking west to the Coastal Range, N/W of Rickreall, Willamette Valley, OR, during a 4 day bike tour w/ friends and family]