Considering the wishes of upstream projects

Close up of waves breaking on smooth rocks

Operating system distributions — and other projects that bundle software — are typically not focused on writing new code. Instead, they package the work of upstream projects into a useful compilation. This introduces the possibility of conflicts between the wishes of the distribution and the wishes of the upstream.

In the ideal case, the distribution and the upstream project work closely together. Perhaps upstream contributors maintain the package in the distribution. They certainly share bug fixes and other patches with each other. They coordinate changes to defaults, collaborate on testing, and so on.

But the ideal case isn’t always reality. The upstream project may have no interest in participating in the distribution. Or they aren’t interested in participating in all of the possible distributions, and dealing with conflicting downstream defaults. In some cases, they may actively oppose their software being included in a distribution. This is often because the project is abandoned and they don’t want to get bug reports for it.

So what’s a downstream distribution to do? In general, you should respect the upstream project’s wishes when you can. Open source licenses mean you don’t have to, but that doesn’t mean it’s not antisocial. At the same time, distributions should be opinionated. If you have a sound reason for ignoring upstream’s wishes, do it. But understand you may get no support — and maybe even hostility — from them.

Photo by Ben Cotton used under the CC BY-SA 4.0 International license

Ben formerly led open source messaging at Docker and was the Fedora Program Manager. He is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.