See Greg DeKoenigsberg's excellent postmortem blog post.
This document summarizes discussions members of the Fedora project have had with ISVs in the past. It should be helpful to ISVs deciding whether or not to ship their products in Fedora. This document assumes that your product satisfies the
Fedora Licensing Guidelines.
Handling Dependencies
To begin there is a philosophical difference between how ISVs and Fedora handle dependencies. It's important to highlight these differences and their motivations.
ISVs bundle dependencies on GNU/Linux for these reasons:
- To provide specific versions, including custom ones.
- To test a coherent whole and know that's what will be deployed.
- To simplify installation.
- To unify their GNU/Linux and Windows release processes.
If a security problem is discovered then the ISV will fix it in the next release or will provide an update mechanism as part of the product.
The Fedora point of view is different since Fedora is not an ISV, but rather a complete system provider. Fedora favours a single point of maintenance for each software component over absolute binary predictability of dependencies for any given package. Fedora's goal is to reduce the global maintenance burden of the entire system; especially for security updates but also for general bug fixes and enhancements.
Shipping and Maintenance Issues
These are contrasting view points on how to ship and maintain software. So what do ISVs gain and lose by doing things the Fedora way?
Gains
- Reduced maintenance burden for all dependencies that are already packaged in Fedora: no need to ship security updates for those components.
- Code auditability: the Fedora packaging processes ensure that all code is described by metadata (i.e., spec files). The packaging tools allow this data to be queried in informative ways. ISVs don't necessarily track this data otherwise.
- Availability of package-specific expertise: ISVs can consult other packagers about the upsteams of their dependencies. Each Fedora package maintainer acts as a known point of contact for their package's upstream project.
- The trust of Fedora users: ISV products packaged in the Fedora way will be more warmly-received by Fedora users than standalone GNU/Linux binaries.
- Stability on Fedora: standalone binaries break frequently because Fedora is such a fast-moving target. Built-from-source packages have proven much more stable, since incompatilities are caught during mass rebuilds.
- Bug triaging: Fedora users report bugs to Red Hat Bugzilla first; the package maintainer decides if it's a packaging bug or an upstream bug. If it's an upstream bug the packager will ideally create a minimal test case and send it to the upstream maintainers.
Losses
- Binary dependency predictability: dependency updates may mean that the deployed set of components is not the same set of binaries the ISV tested during their release process.
- Unity with Windows release process: someone on the ISV's team will need to be a Fedora contributor or they will need to recruit an external packager.
- Ability to customize dependencies arbitrarily: there are rare cases where Fedora ships different versions of the same component for compatibility but in general this is strongly discouraged; custom patches should be sent upstream or eliminated by patching the product's code to not require them.
- Download counting/tracking: if an ISV provides a tar-based distribution from their website, they can track counts and/or emails. This may be important for their marketing department.
Specific Recommendations for ISVs
Specific recommendations for ISVs considering packaging their products for Fedora:
- Don't ship standalone GNU/Linux binaries at all: rather, direct users to Fedora's yum repository from your download page. This has two main advantages: 1) users know to report bugs in Red Hat Bugzilla, and 2) you won't get bug reports against code you don't control if some Fedora dependency is breaking your application.
- Decide if you can trust other package maintainers: ISVs have trouble with this -- the standard fear is that if a dependency maintainer makes an update it might break their package. This is a genuine concern, but keep in mind that Fedora packagers are in general responsible and well-meaning. If an update does break something within Fedora, then it's considered a bug that should be fixed. Basically you have to trust the other packager to a) not break you in the first place and b) fix the problem quickly if breakage does occur. The Fedora tools support a) by providing an easy way to list your dependants (repoquery). You can improve your chances of stability by making dependency maintainers aware of your package so that they can add it to their test regimen when shipping updates.
- Decide if you can accept the losses listed above.
Join Fedora
If you are an ISV that wants to get your software into Fedora, join the Fedora ISV special interest group: