In the Unix world, “portability” refers to porting to different Unix versions. For a GNU program, this kind of portability is desirable, but not paramount.
The primary purpose of GNU software is to run as part of the GNU operating system, compiled with GNU compilers, on various types of hardware. So the kinds of portability that are absolutely necessary are quite limited. It is important to support Linux-based GNU systems, since they are the form of GNU that people mainly use.
Making a GNU program operate on operating systems other than the GNU system is not part of the core goal of developing a GNU package. You don’t ever have to do that. However, users will ask you to do that, and cooperating with those requests is useful—as long as you don’t let it dominate the project or impede the primary goal.
It is good to support the other free or nearly free operating systems (for instance, *BSD). Supporting a variety of Unix-like systems is desirable, although not paramount. It is usually not too hard, so you may as well do it. But you don’t have to consider it an obligation, if it does turn out to be hard.
For the most part it is good to port the program to more platforms, but you should not let take up so much of your time that it hinders you from improving the program in more central ways. If it starts to do that, please tell users that you don’t want to spend any more time on this—someone else must write that code, debug it, document it, etc., and then you can install it.
You can reject porting patches for technical reasons too, as with any other patch that users submit. It is up to you.
The easiest way to achieve portability to most Unix-like systems is to use Autoconf. It’s unlikely that your program needs to know more information about the host platform than Autoconf can provide, simply because most of the programs that need such knowledge have already been written.
Avoid using the format of semi-internal data bases (e.g., directories)
when there is a higher-level alternative (readdir).
As for systems that are not like Unix, such as MS-DOS, Windows, VMS, MVS, and older Macintosh systems, supporting them is often a lot of work. When that is the case, it is better to spend your time adding features that will be useful on GNU and GNU/Linux, rather than on supporting other incompatible systems.
If you do support Windows, please do not abbreviate it as “win”. See Trademarks.
Usually we write the name “Windows” in full, but when brevity is
very important (as in file names and some symbol names), we abbreviate
it to “w”. In GNU Emacs, for instance, we use ‘w32’ in file
names of Windows-specific files, but the macro for Windows
conditionals is called WINDOWSNT. In principle there could
also be ‘w64’.
It is a good idea to define the “feature test macro”
_GNU_SOURCE when compiling your C files. When you compile on GNU
or GNU/Linux, this will enable the declarations of GNU library extension
functions, and that will usually give you a compiler error message if
you define the same function names in some other way in your program.
(You don’t have to actually use these functions, if you prefer
to make the program more portable to other systems.)
But whether or not you use these GNU extensions, you should avoid using their names for any other meanings. Doing so would make it hard to move your code into other GNU programs.