The team I'm working on is planning to build parts of our system for both Windows and Linux. We're unsure how much overhead we should calculate into our time-estimates.

The relevant parts will be implemented in C++ and probably 99% of platform-dependent stuff we'll need can be covered by boost. Nevertheless, we'll need continuous integration for both platforms and although we're using a standardised programming language we assume there will be stuff that doesn't just compile neatly on both platforms or unit tests that don't just run on both platforms and will therefore need time to sort out. We're also mostly Windows programmers (we have access to experienced Linux programmers for support though).

We're currently calculating with an overhead of 25%. Has anyone here any experience with cross-platform development using C++ on Windows and Linux and can tell me if that is a reasonable assumption?

This is a great question.. My gut-level guess would be to add more time on your first such project, perhaps as much as 50% extra. After the first project you'll have a much better feel for it and learned the most important parts of the process. But on the first project, i think 25% additional time is being too optimistic.

Jenkins should be able to handle that for you, we're running it here both on Linux and Windows (mostly for Java and .NET stuff though, but it should handle standard make stuff with ease), and it's quite easy to run, once you've installed a bunch of plug-ins.

Are you going to target ONE specific linux distribution, or are you going to try and aim for "linux in general"? Keep in mind that a lot of opensource programmers consider "portable" to mean "works on (most) linux distributions", and there's enough work on making code work there... which has led to horrible atrocities like autoconf.

Don't underestimate how much time you'll be spending

I guess we should also ask: is this background service kinda stuff, or something with a GUI, or...?

Most Linux distributions would be good enough for us. But this part of the system really has little platform-specific stuff, i.e. it's mostly "business logic" (if you can call it like that) and typical OS stuff which is well covered by boost (file I/O, threading, I/O covered by ASIO, networking).

Concerning GUI: we're currently assuming that we will not be able to come up with the kind of GUI we want with one of the available GUI libraries (like GTK). So we'll most certainly make the GUI Windows-only. If the decision was made that the GUI needs to run on Linux as well, I would certainly calculate with more than 25% for that (despite using a library).