So once an entity decides to "open up" its proprietary product, what does it entail? Porting to open source operating environment is not similar to that of porting to a tightly managed operating environment (Windows, MAC OS X, HP-UX, Solaris) since there are more than a dozen varieties of Linux operating environments in the market, amongst them Ubuntu, Redhat, SUSE, Debian each with their own intricacies. Of course one can decide to build its own distro from scratch.
Moving to open source does not alleviate typical development functions s.a. coding, testing and qa, builds and packaging, not mentioning the governance (licensing issues) requirements.
Open sourcing products provide tremendous advantages amongst them contribution to the code base by thousands of open source enthusiast throughout the world. However, the decision of "which distribution" to start with or which ones to conform to may not be a trivial one.
Deciding which distribution
I think you may be over-thinking this a bit.
Once you have actually completed the part where you provide the source code under an open license, packaging the software for distribution to users should be easy to determine. Questions to ask yourself:
What is your available/desired operating system?
You should easily be able to test installation issues using your own environment(s) first. If you do not have Windows XP 64bit, don't worry about packaging and installation for it. If you do not have a Mac, there is no need to worry about whether to support 10.3, 10.4, 10.5, or 10.6.
Who is the intended audience?
If your application is for home users (like a recipe manager or DVD collection app), then provide a .MSI file for Windows, an Ubuntu .DEB file, and a Mac.app. I would rank these as the 3 most common OS environments.
If your application is for commercial users (like an network analyzer or a grid-control application for high-level computing), then what is the OS that your intended audience will be using? For instance, math/science institutions lean toward Linux (CentOS, RedHat, SuSE, and Ubuntu) or even OS X.
Is my application intended to be completely cross-platform?
If yes, then find users with the desired platforms to help you test compilation and packaging. Or, in the case of some Java and Python code, just have them run the application.
Use the right methods and tools to support diversity
I think that the Unix world since it's origin is split between 2 incompatible tracks: Standards and innovation. On one hand think POSIX, on the other, the great variety of tools to achieve what you want.
Linux as every Unix doesn't differ. But there are much less differences between 2 linux distributions for someone coding, than between 2 Unices. However, from an administratot point of view, there are more.
That's why I'm working on project-builder.org in order to ease some of those problems from a packaging point of view, by sharing all metatdata in a project that are needed to build packages. And I'm with it supporting more than 60+ distributions-versions-architecture tuples currently (look at ftp://ftp.mondorescue.org to get an idea). It's even supporting OpenSolaris now :-)
So i'd recommend to stick to standards to make your job easier (LSB and FHS rules) and use some additional tools that aims to streamline the support of multiple linux distributions (or more). It's not more work. Just needs to be done right from scratch, instead of not taking it in account. Then results are portable applications, and easy support cycle.
And that's not just an ideal and a dream, as I'm working like that everyday since 3 years now.
Bruno.
--
Linux Profession Lead EMEA & Open Source Evangelist
http://opensource.hp.com - http://hyper-linux.org