开源软件是开发中的关键资产，因为它允许开发人员在其他人的基础上构建，并在紧张的时间安排中将更多的时间用于构建核心业务价值。最大的价值可能不是基础设施组件，而是可以减少开发人员必须创建的代码数量的框架和库。经常与开源公司开始通过基础设施组件,例如CentOS, Tomcat,或MySQL,但开源的更大的价值,在我看来,是生产力的增加来自于利用最广泛的基础框架和库可用于减少投放市场的时间的功能开发。今天的开发更多的是构建解决方案，而不是从头开始完全编码这些解决方案。开源提供了可用于构建的最广泛的组件集。
最近，我在两篇独立的博客文章中提到了这种价值。其中一篇是我们的工程师Jeff Gran的一篇文章，他总结了为什么开源通常是高质量的以及为什么开源的几个原因软件对他的开发至关重要。开放源码社区包含一组广泛的解决方案，其中许多是针对特定问题的库。他们经常遵循“做一件事并把它做好”的咒语。这创建了有针对性的解决方案，这些解决方案的审查人员比开发组织通常拥有的人员多得多。这些经过良好测试的、有针对性的解决方案成为可以提供预制基础的基石。
另一个提醒来自于一个完全不同的观点，谈论了创建软件的过程。这是一个讨论苹果公司最近的管理层变动。虽然我对苹果公司的管理团队并没有什么特别的见解，但文章中的一段确实引起了我的注意:
与乔布斯时代不同的是，在乔布斯时代，公司只会在功能准备就绪的时候发布，而日程安排驱动的发布文化已经变得司空见惯。
Siri和地图之所以还不成熟，还遭到嘲笑，原因之一就是基于时间表的安排。苹果内部的许多工程师都能预见到地图的问题。为什么?因为地图是由时间表驱动的。
现在，我参与过的大多数公司和项目都是在满足特定期望的同时，为客户和潜在客户提供价值。企业要想成功，就必须能够预见未来，并在适当的时候向市场交付产品。为了实现这一愿景，企业还需要在销售、市场营销和工程设计之间进行许多复杂的协调工作。除非你足够幸运，成为像苹果这样的5000亿英镑的巨头，或者拥有一组非常特殊的客户，否则你很有可能遇到这样的情况:需要功能，资源基本上是固定的，因为底线是王道，而那些讨厌的截止日期变得非常重要。从发展的角度来看，试图限制这三个因素就像试图建造一幢足够坚固的建筑在地震中不会移动一样。压力的增加会导致某些东西破裂。在软件方面，质量将受到打击。
时间框的敏捷方法，比如Scrum，通过允许截止日期很重要，并且资源是固定的，因此可以实现的特性数量必须是灵活的来适应这一点。这允许在可预测的时间框架内实现较少的高质量特性。精益敏捷方法，比如看板，试图通过接受特性是重要的并且应该在它们准备好时发布，同样使用固定的资源，尽管确切的交付日期可能有所不同。开发人员在许多(大多数)情况下都是非常糟糕的评估者，因为创建软件有点像一门艺术，这就是为什么经常谈论“理想时间”和“捏造因素”的原因。不幸的是，当特性和时间轴是业务需要时，即使对一些最需要敏捷的涉众来说，这两种方法都可能导致头疼。
当这个功能的最后期限的怪物出现,和是必要的,你可以让红牛和卸扣开发人员办公桌(希望走捷径并不是通过节省测试覆盖率),或者你可以准备您的团队通过让他们获得一个巨大的仓库准备好了组件,会让他们更有效率和灵活的完成工作。
