本文档旨在描绘出OpenSSL项目的路线图。它是一个会日臻完善的在线文档。它应该被设定理想的目标和里程碑日期。
OpenSSL 项目当前看起来越来越迟滞和封闭。本路线图将尝试通过设定一些带有具体里程碑日期的目标来解决这个问题。
目前的问题
OpenSSL项目目前正面面临一些问题，它们是:
1.RT积压
开放以来的相当长的一段时间，RT的已经积压到了一个显著的数量. 这些问题中的大部分事实上已经被处理了，所以应该被关闭，但是却没有被记录在系统中。而大多数都尚未被关注.
2.不完整/错误的文档
OpenSSL的文档目前是碎片状的。一些部分由很好的文档，而许多其他的部分则是不完整或不正确的.还有许多部分甚至都没有文档.
- 负责的库
OpenSSL的库不管是从维护的角度，还是从用户的角度来看，都是复杂的。 公共的API中包含了许多本应被内置的东西。代码已经被移植到了大量的平台中，它们中的许多都已不再为今天的我们所关注，而这让代码库更加复杂化. 代码的一些部分很长一段时间都一成不变，需要更新. 而它对FIPS的支持则更加复杂.
复杂性将导致维护上的问题，并且也是用途模糊和难于查找安全漏洞的问题之源. 它也使得用户使用起来更加的困难，特别是同上述第二点纠结在一起的时候.
当前的内存管理代码已经是问题和漏洞的一个来源了.
- 不一致的编码风格
已经有不少的开发者在代码库上工作了多年。代码中使用了许多种不同的编码风格，这造成了混乱，并使得维护更加的困难. 即使是严格的一直，当前的代码布局也是异乎寻常的五花八门，不同于任何其它的开源软件.
- 缺少代码审查
我们没有代码审查，也没有强制要进行代码审查.
- 没有明确的发布计划
历史上的OpenSSL在没有规律的基线上发布新特性，而且也没有远景计划发布. 对于用户来说很难为新的发布制定计划，也很难在新特性可能到来，或者某些支持将随着发布而结束时及时理解. 另外OpenSSL开发团队还维护者大量的稳定版本——这挪用的开发最新版本的资源.
- 没有明确的平台战略
历史上OpenSSL对平台的支持非常广泛。通常对平台的支持会在每一个平台的基础上添加“ifdef"条件编译. 这种方式已经造成了诸多问题:
- 代码已经变得非常的混乱，一直难以进行有效的维护
- 代码中还存对许多不会在今天进行大规模部署的传统平台的支持 - 如果代码设置还能在那些平台上运行的话
- 实践中开发团队并没有接触过如此多的平台，代码库的支持和测试通常限制在一个非常有限的集合内(常常是 Linux, FreeBSD 和 Windows)
**1.没有发布安全策略
**
我们并没有知名的，并且是发布了的方法，用来处理如何就安全事项适当的告知对此感兴趣的组织和安全专家，这一问题.
目标
上面所指出的问题中每一个都可以转换成高层次的目标. 其中一些可以比其它更加容易和快速的达成.
一个重要的原则就是，对这些目标的关注，以及它们的优先级，都将在交付新特性这一任务之上.
RT 解压
1.用一种设定时间线的方式将所有新提交的RT项都管理起来，比如在四个工作日之内要做出初步的响应. (时间刻度: 现在)
2.RT积压要随着时间逐步减少 (时间刻度: 正在进行).这可能会包含大量尘封已久的非常老的RT项， 比如那些比任何当前支持版本都要早提交的RT项
**
不完整/错误的文档**
１.为所有公共的API提供完整的文档（不包括过时的API）（时间线：一年之内)
１.这可能要引入一个新的文档系统
２.API的一些部分历史上曾是公共的，但并不打算供公共使用, 比如低级别的加密和摘要API. 这些部分可能没有文档, 或者可能要打上过时的标记(时间线: 9个月之内).
复杂的库
1.审查并修订公共API，以降低其复杂度 (时间线：一年之内)
2.提供一份平台战略文档：见下文(时间线：三个月之内)
3.审查并重构FIPS的代码，降低其受侵扰的程度(时间线：一年之内)
4.审查并重构内存管理的代码(时间线：六个月之内)
**
不一致的代码风格**
１.为项目制定一个明确的编码标准。它不仅将涵盖代码布局，还将涉及如何处理平台依赖，单元测试以及可选代码这些项目（时间线：三个月之内)
２.根据通过的标准格式化整个代码库. (时间线：在编码标准被明确的三个月之内)
3.依照风格指南的其它部分重构代码. (时间线：一年之内)
代码审查
1.商定并实现一个流程，以便所有新的提交都能首先被熟悉相关代码的团队成员更新，直到审查者提出的问题被解决. 这需要招募足够多的团队成员来使得代码审查或多或少总是能维持下去. (时间线：三个月之内)
2.商定一个代码审查系统. (时间线：六个月之内)
审计
1.要有对当前代码库的外部审计. (时间线：依赖于外部主体)
静态/动态分析
1.采用合适的工具定期对代码进行审核. (时间线：六个月之内)
发布策略
我们需要制定一个发布策略，以确定我们计划何时发布产品，以及更新的频率，该策略也会确定我们需要提供多长时间的技术支持，和何时该版本的生命周期结束。（时间线：3个月）
我们要为这个发布策略寻找并确定多个目标，某些目标之间会出现冲突，需要互相妥协，它们是：
1.我们需要在不造成任何破坏的情况下发布安全补丁，这很可能会使稳定版本中的新特性无法使用（也就是免除责任通告）。
2.如果某个发布版本中出现了缺陷，修正版本应当很快发布（免除更多责任通告）。
3.我们需要一种方法，能够尽快使新的二进制文件融合到OpenSSL中。
4.我们不希望维护太多分支，这可能意味着0.9.8版本的生命期的结束。
5.我们需要一种重构代码的方法，能够生成必要的二进制文件，而且不再支持被修改的代码、被废弃的API等。
