Yes if you actually write software for desktop Linux you know that it's not that much of a problem to actually do it if you want to. There is enough free software available, you know often written by individuals without multi-million dollar budgets, that I have not had need for using a Windows machine other than to compile software for Windows machines. If multi-million dollar companies actually wanted to support Linux they could do it without breaking a sweat. The only reason they don't is because Windows user base is so large and Linux's is so small that the benefit does not justify the cost.

All you have to do is add a significant user base, say 5-10% of the market and it will be competitive with Mac and I am sure there will be lots more commercial software for it.

I would also like to mention that my sister is a total computer dummy. Her computer always gets infected with malware and lots of it. But I installed Linux on it because I did not have a Windows install disk. And she loves it because it doesn't get malware anymore. And she loves the fact that she can install free software using Ubuntu's software center. That's a true story.

For what it's worth, I had the same experience with my parents. I installed Ubuntu on my dad's laptop and my mum's desktop. They loved it for quite a while - it was much faster, no security problems and no weird errors. I was so happy that I left a few comments online similar to yours.

A year or so later, they both use Mac. In both cases, the inevitable question came "so I bought this <peripheral/software>, how can I get it to work?".

I did the same with my parents and they still use Ubuntu.

When they want some hw or sw, they ask what would I recommend. They realize that they know nothing about it and do not want to buy some crap.

If you develop for Ubuntu and Fedora, many distributions will mostly work with your program : all Ubuntu flavours (Unity, GNOME, XFCE, KDE) and derivatives (Linux Mint, Elementary), maybe Debian, Fedora flavours (GNOME, KDE) and derivatives (Red Hat, CentOS), etc. You'll have to decide for a widget toolkit (Gtk+ or Qt), but a Qt program will run fine on GNOME (the design won't be perfect, but it's like a Qt program on Mac OS X or Windows). Dependencies isn't the big problem : you have a single sound server to look for and other drivers aren't important for a simple program.

Of course it's complicated, more complicated than Windows, depending on your type of program. But seeing how Valve made it work for games, I think it's going to be seen more and more.

At work all our desktop software was ported to linux and it works fine. Linux web servers, of course, mostly. Well there are some non linux web applications and numerous embedded devices with web access.

All I run natively is MS office stuff, chrome/ff, and vpn/vnc/ssh remote access type stuff. I have a linux desktop box on my desk running all the remote stuff plus native emacs that I use for most real work, the little old MS box is just for opening Excel sheets and legacy Word docs occasionally.

Its been a long time since I've run a non-MS (and non-chrome non-FF) binary on a MS desktop at work. Many years at least. The future is the web not native apps. IT will no longer deploy native client apps as a policy, so its not like any are officially ever coming back.

Decades ago its amusing to recall how much work IT folks had to do to install dozens of 3rd party applications on desktops before we'd get to use them. We had multipage checkbox forms. Now its "office, FF and chrome" and some corporate secret sauce (corporate anti-virus whatever type stuff) and they're done. A more draconian employer would just install office and force minions to use MSIE. And google docs and competitors are taking over all non-corporate "productivity app" work. With web access and outlook web mail and free viewers, technically most worker drones don't need anything more than a MSIE bootloader, although its more humane to let people use FF / Chrome.

For most employees, if it boots and runs FF or chrome, that's all they use to earn their pay, so no difference if MS, linux, freebsd, or mac.

We have that problem for our desktop apps. Supporting the Windows and Mac versions is much easier than supporting Linux AND Linux has less users.

> display managers

You mean "window manager", right? Why would depend on a specific WM unless you were writing a WM-specific utility where no decision would be necessary? Your application only needs to target X11, which is implicit when you use a pre-existing toolkit.

> audio devices

What audio devices? Just write to the default ALSA device. Better yet, delegate the problem by linking to something like OpenAL.

I'm sure there are edge that are more complicated to port, but that is true for any OS. For most apps, porting shouldn't be particularly difficult.

> For most apps, porting shouldn't be particularly difficult.

But making sure that it runs under a sufficiently large number of distributions/versions of distribution is under GNU/Linux.

This may be true for games, but it's less of a problem in general. If you don't want to release the sources and have it handled downstream, you can always statically-compile everything and call it a day. Most commercial vendors tend to do that. Display managers are pretty much irrelevant, I can't think of any application that cares if you're running gdm, sddm or anything else; the ALSA backend pretty much guarantees everything is fine in the sound department.

I guess it depends on how many dependencies you're relying on and on what those dependencies are, but the process is pretty smooth.

If they manage to develop things for Android, it can be done for Linux, too.

(Source: developed and packaged a commercially-distributed Linux application. Not too painful a process.)

This can be solved by containers.

It doesn't need to be solved by containers. I can easily import KDE packages onto my lubuntu distribution and everything just simply works.

This has been solved for ages. Containers can help in some particular scenarios, but they're neither the only, nor the perfect solution, by far.