How to explain that writing universally cross-platform C++ code and shipping products for all OSes is not that easy?

Question

Our company ships a range of desktop products for Windows and lots of Linux users complain on forums that we should have been written versions of our products for Linux years ago and the reason why we don't do that is

• we're a greedy corporation
• all our technical specialists are underqualified idiots

Our average product is something like 3 million lines of C++ code.

My and my colleagues analysis is the following:

• writing cross-platform C++ code is not that easy
• preparing a lot of distribution packages and maintaining them for all widespread versions of Linux takes time
• our estimate is that Linux market is something like 5-15% of all users and those users will likely not want to pay for our effort

when this is brought up the response is again that we're greedy underqualified idiots and that when everything is done right all this is easy and painless.

How reasonable are our evaluations of the fact that writing cross-platform code and maintaining numerous ditribution packages takes lots of effort? Where can we find some easy yet detailed analysis with real life stories that show beyond the shadow of a doubt what amount of effort exactly it takes?

Answer 1

Keep in mind the majority of people are employees, and thus don't live in a world where they need to care about making a profit. They show up at work, do their thing, and go home, never really giving a thought to how the whole process works. And while very smart, a lot of techies are positively ignorant about business, and often blinded by dogma.

You are right, of course, making x-platform software of that scale is not a simple thing. Particularly when you arent a company that has many dozens of developers and millions of users. And its not just technical limitations. Its all about cost vs benefit. Yes, you could spend then next year porting the app to Linux (despite, as you note, it already being runable in WINE). Of course, that year of development time doesnt come free. And in the end, will net you maybe an additional 5-15% users (based on your estimate). Or you can take the same money/effort, and focus it into your Windows development as a new version, or put it all into marketing, and add 50% to your user base. Which sounds like the smart choice? (obviously the numbers need to be customized to your company, and the final outcome may favor porting).

I dont know if that will help persuade 'true believers', but its the smart business move. And if you dont make smart business moves, you're out of business. And then there wont be a Linux version for sure.

Answer 2

Adobe, is that you?

Seriously though, put up some kind of a bounty so they can preorder Linux versions. If you get enough orders to make a port worth it put in the time, otherwise refund them and you now have proof not enough people care to make it worthwhile.

If you get something ported though, just target the latest Ubuntu LTS release, RHEL, SLED, and perhaps provide a tar.gz people can try to get working if they want to use something else. That leaves you with 3 packages to worry about and anyone else probably knows enough to get the tar.gz version going.

Answer 3

There are two things to consider here I think:

The first is that, in a way, they are right. Writing cross platform C++ isn't that hard if you planned for it from the beginning. This is almost certainly the problem you're seeing. Most open source applications (most of the applications a Linux user touches on an average day), are absurdly cross platform. Think about the number of applications the average Linux user interacts with daily that are written in C or C++ and run not only on Windows and Linux, but also MacOS, BSD, Solaris, etc. on x86, x86-64, ARM, SPARC, etc. This is partly because people with an itch to scratch port the code to run on their systems, but also because then convention is to plan for cross platform portability.

The second thing is, the market may be more viable than you think. There is a huge misconception that people on Linux don't want to pay for software. For some people that may be true, but there are a lot of people (most, I think) who use Linux because it works better for them and they prefer it, not due to price. Also, if your company is producing a product that is used primarily in a professional setting, companies are well used to paying for software to run on Linux systems.

As for the point you make about packaging, as others have said, you really just need to produce packages for the latest version of the major distributions. Actually making the packages is not really all that hard, and most of the major distributions are using either debian packages (debian, ubuntu, etc.) or RPMs (fedora, suse, centos, mandrake), so it's very minor to modify some scripts to produce multiple packages from a baseline .deb and a baseline .rpm, and for everyone else just throw up a tarball with binaries and a readme, people will figure out how to get it installed. Alternatively, you could skip all packaging, and just post a single tarball with a bash or perl script to do the installation.

As for how to address the users on your forums complaining, as Joe Internet said, they might just be the percentage of people who are going to complain no matter what, but the first thing I'd do is try to explain that you have a large amount of legacy code that wasn't designed with cross platform support in mind. Second, honestly see if it would make financial support to make a Linux port, and be open with the results of that. Finally, if a port isn't financially feasible, see about doing some work to make the program work well with WINE. WINE shouldn't be the first solution, but it may well mollify the people who just want to use your app in Linux, and be a less expensive project than a full port. In fact, if you add code to the WINE codebase as part of the project, then not only could you open yourself up to a new market, but you could also get significant goodwill from the community.

Answer 4

With attitudes like that, I would just ignore them. They sound like the segment of X, where X can be anything, that will complain no matter what you do. Release a Linux version or not, that's your choice, not theirs.

Answer 5

writing cross-platform C++ code is not that easy

Quite the contrary. When you plan for cross-platform work, and provide abstractions for the platform-specific APIs you use, the vast majority of your code is already cross-platform. If you're already using a popular library like Boost or Qt or NSPR, you're already very close to having a working cross-platform build.

The problem most commonly experienced when doing a port late in the development cycle is that there are significant portions of code that rely on platform-specific APIs in parts of the program that needn't use them directly and probably shouldn't at all. (A good design will have strongly decoupled modules, and groups of classes can be swapped out with rewritten replacements at will. If this is not the case for a given module, it is a strong code smell.)

The easy way out is often to just write a "Utility" class and toss all of your platform-specific stuff inside there. It's not "easy and painless," but certainly less hard than you might think.

preparing a lot of distribution packages and maintaining them for all widespread versions of Linux takes time

This is an unfortunate misconception. While it is true that maintaining builds for multiple platforms requires additional effort (in setting up a dedicated daily build server and learning how to package for a particular distribution), it's not true that you need to maintain them for "a lot of distribution[s]." Quite the contrary. You need only maintain a small handful of packages -- say, perhaps, Ubuntu, Fedora, and a single LSB-compatible tarball -- and the various Linux communities will take up the rest of the work. Especially if your software is popular, HOWTOs will spring up for every distribution, providing needed setup instructions. Or, if your software can be freely distributed (which you can do even if it's not a free product, provided your licensing allows it), the more popular distributions will have some kind of alternate repository carrying copies of your software.

The communities are generally very good about this, and experienced users will willingly do a lot of this legwork for you, if you let them.

our estimate is that Linux market is something like 5-15% of all users and those users will likely not want to pay for our effort

Another unfortunate, and very mistaken misconception.

Just because Linux users get their operating system for free does not mean they're unwilling to pay for software. If the software is very good and there is wide demand for it, Linux users will often be more willing to part with their money than your Windows users will be. Just look at the Humble Indie Bundles, where Linux users, on average, paid more than twice as much per user as compared to Windows users.

It's also possible that your product may have greater demand among Linux users than on other platforms (which we can't know without knowing of your product), depending on what kinds of existing software there is in that arena. You may have a larger potential market than you realize.

Answer 6

If you work for Nvidia...

For the love of god, suck it up and write some decent drivers already.

Otherwise, if you're doing regular business applications, target future projects to run on C#.

Mono is fully compliant up to .NET 3.5 and can even use winforms GUI. The only modules you need to watch out for are the OS specific ones but they're few and far between.

Answer 7

Try to explain to them what are C++ templates, and the pain it is to compile them in all compilers. Then explain that the C++ standard lib, used them...