在 Unix 世界中，“可移植性”指的是移植到不同的 Unix 版本。对于 GNU 程序来说，这种可移植性是可取的，但不是最重要的。
GNU 软件的主要目的是作为 GNU 操作系统的一部分运行，使用 GNU 编译器在各种类型的硬件上编译。因此，绝对必要的可移植性种类是相当有限的。重要的是要支持基于 Linux 的 GNU 系统，因为它们是人们主要使用的 GNU 形式。
使 GNU 程序在 GNU 系统以外的操作系统上运行，并不是开发 GNU 软件包的核心目标。你永远不必这样做。然而，用户会要求你这样做，并且配合这些请求是有用的——只要你不让它主导项目或妨碍主要目标。
支持其他自由或近乎自由的操作系统（例如，*BSD）是好的。支持各种类似 Unix 的系统是可取的，尽管不是最重要的。通常这并不太难，所以你也可以这样做。但是如果它真的变得很困难，你不必认为它是一种义务。
在大多数情况下，将程序移植到更多平台是好的，但不应让它占用你太多的时间，以至于妨碍你以更核心的方式改进程序。如果它开始这样做，请告诉用户你不想在这方面花费更多时间——其他人必须编写该代码、调试它、记录它等等，然后你可以安装它。
你也可以出于技术原因拒绝移植补丁，就像用户提交的任何其他补丁一样。这取决于你。
实现与大多数类 Unix 系统可移植性的最简单方法是使用 Autoconf。你的程序不太可能需要了解比 Autoconf 可以提供的更多关于主机平台的信息，仅仅因为大多数需要此类知识的程序已经编写完成。
当有更高级别的替代方案（readdir）时，请避免使用半内部数据库（例如，目录）的格式。
至于不像 Unix 的系统，例如 MS-DOS、Windows、VMS、MVS 和较旧的 Macintosh 系统，支持它们通常需要大量的工作。在这种情况下，最好花时间添加在 GNU 和 GNU/Linux 上有用的功能，而不是支持其他不兼容的系统。
如果你确实支持 Windows，请不要将其缩写为“win”。请参阅商标。
通常，我们完整地写出“Windows”这个名称，但是当简洁性非常重要时（例如在文件名和一些符号名称中），我们将其缩写为“w”。例如，在 GNU Emacs 中，我们在特定于 Windows 的文件的文件名中使用 ‘w32’，但 Windows 条件的宏称为 WINDOWSNT。原则上，也可能存在 ‘w64’。
在编译 C 文件时，定义“特性测试宏”_GNU_SOURCE 是一个好主意。当你使用 GNU 或 GNU/Linux 进行编译时，这将启用 GNU 库扩展函数的声明，如果你在程序中以其他方式定义相同的函数名，通常会给你一个编译器错误消息。（如果你更喜欢使程序更容易移植到其他系统，你不必实际使用这些函数。）
但是，无论你是否使用这些 GNU 扩展，都应该避免将它们的名称用于任何其他含义。这样做会使得将你的代码移入其他 GNU 程序变得困难。