I've read several articles on Linux lately where some are concerned that since Ubuntu has set itself up as the premier Linux distribution, that many developers will develop for it and therefore their programs will be incompatible eventually with other distros, like Steam for example. What are your thoughts on that? Do you see that happening?
That could absolutely happen, but only for commercial applications.
Although Ubuntu has a fairly large user base, especially compared to most other Linux distributions, it doesn't have as many highly technical users. Most open-source developers develop for GNU/Linux in general, and don't particularly care what Canonical does with Ubuntu. Their software works on Ubuntu with little-to-no modification because Ubuntu is still reasonably similar to other Linux distributions at its core. Unity started to change some of that. Now GNOME indicators must be completely re-written for Unity, and most applications need to be explicitly patched to support Unity's global menu bar integration. Similarly Upstart, Canonical's in-house init system, makes it more difficult to keep system services in sync between Ubuntu and Debian. Once again, Canonical uses their limited development resources to patch an ever-increasing amount software packaged in Debian to work with their solutions. No other major distribution is using Unity or Upstart, apart from those derived from Ubuntu, so open-source developers feel no particular need to maintain the integration patches. Ubuntu is diverging from other Linux distributions by shunning standardized solutions.
While this divergence will absolutely hurt Ubuntu in terms of open-source development, the trend seems to be exactly the opposite for closed-source development. I do not think this is cause-and-effect. Proprietary developers seem to be attracted to Ubuntu because it is an easy-to-use Linux platform with professional support options. Unlike Debian, Arch, or most other traditional Linux distributions, Ubuntu is backed by a corporation that can make concrete support commitments. While power users and open-source developers don't particularly care about commercial support, closed-source developers do. And unlike RedHat and SUSE - both of which do very well in enterprise Linux support - Canonical targets Ubuntu at end-users. For professional commercial software, such as MATLAB or Maya, standardizing on RedHat or SUSE makes sense. On the other hand for proprietary consumer software, Canonical has worked hard to become the standard. Due to good marketing and a near-complete lack of competition, they have arguably succeeded. Therefore it seems like the logical choice for vendors of consumer software on Linux to standardize on Ubuntu.
Since Ubuntu's divergence from standard GNU/Linux systems has not reach astronomical levels yet, some closed-source developers have tried to implement support for other distributions while still compiling only for Ubuntu LTS. Valve is a good example of this. They compile Steam on Ubuntu 12.04 and support it exclusively on Ubuntu. Since many other distributions have the necessary dependencies to run Steam, Valve provides Steam Runtime so that developers can package Steam for other distributions, yet Steam can still get reliable system information and do proper dependency resolution because of the Steam Runtime distribution hooks. That is a very good approach, but it requires some work for Valve and distribution packagers to support. Therefore many other proprietary software vendors opt for one of two much easier approaches. The first is to create a custom installer that installs the program with all of its dependencies bundled in. While that approach allows the software to near-universally work on a wide variety of GNU/Linux distributions, it makes the software difficult to uninstall and is generally frowned upon by distributions. The dependencies shipped with the program can quickly become obsolete and introduce security vulnerabilities to the system. Therefore the second approach is often used instead as a cleaner, and possibly easier, alternative. This approach is to compile and package software exclusively for one distribution, or even just one release of one distribution. That allows the distribution's package manager to do the hard work of dependency resolution so long as the vendor packaged the software well. The program itself doesn't have to be aware of which system it is running on or which features are available. It can just assume, and hopefully work. The first approach is the best, the third next, and the second the worst. Unfortunately the first two approaches could be broken by forthcoming changes in Ubuntu, particularly the new display server, and I see no good recourse at this time. Commercial vendors will either have to compile their software twice - once for Ubuntu and once for another GNU/Linux distribution - or simply use adopt third approach and alway assume Ubuntu. Given commercial software's track record, the latter solution seems most likely.
There is a looming threat with this situation, and it isn't good for any party. Group number one, open-source developers, largely don't care about supporting any particular distribution. Support is a downstream problem. Some of those developers wear multiple hats and are part of one or more downstream packaging efforts - therefore they are generally very responsive to downstream bug reports and feature requests - but with their upstream hat on they will not give preferential treatment to one distribution over another. Since Ubuntu has such a large user base, open-source developers will be affected by erroneous bug reports due to Ubuntu-sepecific hacks or lack of support for their application in Ubuntu.
Group number two, closed-source developers, largely don't care about supporting as many distributions as possible. They just want to choose a well-supported base and mandate it as a system requirement. This group is also affected by Ubuntu-specific hacks, but in a different way. Either technology used exclusively by Ubuntu or Ubuntu-specific hacks will prevent their software from being used on other Linux distributions. While most commercial vendors currently do not officially support more than one distribution anyway, they unofficially encourage their software's use on other distributions because it widens their user base and buys them more good-will within the Linux community. As we all know, Linux users, especially those on distributions not derived from Ubuntu, tend to be very technical and are generally willing to spend the time to trace bugs and submit detailed bug reports for projects they care about - including those that are closed-source. This is obviously very valuable for those closed-source developers, and would be lost by Ubuntu exclusivity.
Group number three, Canonical, largely cares about achieving their vision even if there is some collateral damage. Unfortunately I think they are stretching themselves too thin by heavily patching software, forking projects, developing their own software, and generally ignoring input from the lion's share of upstream developers. While the first two groups are taking diametrically opposed positions on the issue, they are basically in the same boat. Canonical is burning bridges with their upstreams, incidentally hurting the commercial vendors they have been courting, increasing their own support burden, and ultimately hurting their users.
Despite the somewhat depressing situation, there is hope. There is one party who can do something about this brewing storm: Canonical. Ubuntu already has a unique niche that no one else is filling. It is an established brand. And Canonical already has all the pieces they need to become the commercial Linux vendor they aspire to be; they are just lacking the execution. RedHat is an excellent example of how a successful commercial vendor can support open-source technology: actively participate in upstream development, voice your opinion on future technological decisions, support open standards, and adopt standardized solutions. Canonical can use the same basic strategy but implement it in their own way to achieve their goals. I can see it. It could work. Although they would need to pivot on some backend technology and start participating more closely upstream, that is entirely doable. One of the great things about Ubuntu is that Canonical has already proven that they can (somewhat) transparently move to new underlying technologies without disrupting their users (too much). The future is in Canonical's hands - not open-source or closed-source software developers in the GNU/Linux ecosystem. They are once again at a turning point. Will they continue down their current path or transition to a more tenable model? Ubuntu is not a true community project. Only time will tell how Canonical chooses to handle their unique situation. They will probably never get a chance like this again.