移植一个开源软件包时，一般的经验法则是跟踪您为使它能在您的系统上编译和执行而做的改动，如果您认为这些改动对整个社区有用，就把它们提交给软件包的维护者。通常情况下，这样做的好处是可以减少未来对同一软件包进行移植的工作量。
我已经将许多软件包移植到VOS和OpenVOS上，我通常会试着将我的修改发送给维护者。但并非总是如此。原因是这样的。
1.有些更改是针对OpenVOS环境的。如果我为了绕过一个只适用于OpenVOS的限制而做了一个改动，那么把这个改动发到上游就没有什么意义了。维护者一般会拒绝这种补丁。一个例子是，17.0之前的OpenVOS版本对文件名长度的限制。
2.有些修改可能已经在以后的开源包版本中被采用。在提交任何修改之前，最好先检查一下是否有人比你更早地进行了修改。如果你已经有一段时间没有下载原始的源代码了，那就更应该如此。没有必要用过时的修改来浪费大家的时间。
3.这些变化实际上是在不同的产品中。例如，我最近完成了将MySQL 5.1.48移植到OpenVOS 17.1版的工作。我通过对构建脚本进行各种修改，使它能够使用OpenVOS 17.1上新的动态链接设施。但是把这些改动发给MySQL团队是没有意义的，因为这些改动实际上是在autoconf包里，而autoconf包是由另一个团队维护的。MySQL包只是autoconf的用户，他们无法控制它对任何特定平台的作用。
4.从我拿起软件包的副本到今天已经过去了太多时间。这里的问题是，一个开源包是一个移动的目标。虽然有些包相当稳定，不经常更新，但有些包却在不断变化。 我花了9个月的时间来移植MySQL 5.1.48，因为这是一个兼职的工作，而且即使移植了，我也必须与我们内部的测试和发布流程同步。 所以当我准备把一些补丁发回MySQL团队的时候，他们已经升级到了5.5版本（在一般可用周期）和5.6版本（在开发周期）。 我不得不做的许多改变不再干净利落地应用；在某些情况下，源文件已经被重命名或移动到新的目录。我可以做的工作是把补丁完全更新到当前的版本，但这是一个很大的工作，而且，至少在我看来，不值得付出这样的努力。给我的教训是，我应该在我的版本稳定后就把这些改动发到上游。这显然是一个判断的问题。
有时，你可以采取所有正确的步骤来发送一个特定的、写得很好的、经过精心调试的补丁，但维护者仍然会忽略它或拒绝它。这可能是令人沮丧的，但不要为此而激动。许多开源包都是由志愿者维护的，所以他们处理不常见平台的补丁的时间有限。
在 MySQL 5.1.48 的 OpenVOS 移植中，我选择为 MySQL 软件包中明确定义的、独立的问题打开 5 个特定的 bug 报告，我的研究表明这些问题仍然存在于当前的开发版本中。 我还打开了一个bug报告，这样我就可以回馈我们所有的修改；这一步符合GNU公共许可证的条款。在每一种情况下，我都贡献了一个源代码补丁，显示了我认为适合关闭bug报告的变化。我希望MySQL团队能够整合我所要求的5个具体变化。它们代表了可能影响其他平台的问题，而不仅仅是OpenVOS。如果你想看看我发给MySQL的补丁，请访问http://bugs.mysql.com，点击高级搜索，然后查找错误44300、44832、60907、60908、60910、60911、60912和60913。
MySQL 5.1.48 的 OpenVOS 移植版将被Stratus 称为"MySQL for OpenVOS, Release 2.0"，并将在不久后与 OpenVOS Release 17.1 同时推出。