今年是新的一年，我们将以2020年为重点更新IPFS项目路线图。在此过程中，我们还希望反思自2019年以来的成功、挑战和经验教训，以帮助我们继续朝着实现目标迈进使命，并最大化我们在世界上创造的价值和效用。
回顾2019
对于IPFS项目而言，2019年是令人振奋的一年：
IPFS公共网络在2019年增长了30倍
每天有成千上万的节点参与IPFS网络
每周都有数百万用户访问IPFS HTTP网关
在更广泛的IPFS生态系统中有数百个DApp、工具和项目，其中包括Anytype、Microsoft ION、Haven by OB1、Brave、3box和EthDNS等新来者。
这一增长使我们在年中转移了一些注意力以支持新的用途和需求——将我们的一些工作组重新集中于改进文档、网关性能和测试工具以验证大规模网络升级。我们仍然在实现包管理器目标方面取得了进展，但是比我们期望的要少得多，因为它还在其他关键领域进行了大量投资以支持生态系统。
5个重大举措
我们举办了首届IPFS训练营，这是一个广泛的行星际社区中的开发人员和建造者聚会，学习、共享和演示其工作的聚会。
在实现程序包管理器的目标方面，我们取得了重大进展。
我们与libp2p团队合作开发并推出了TestGround v0.1，这是一个用于测试各种规模的分布式系统和网络的平台。
我们启动了ProtoSchool，这是一个用于提供交互式教程的新门户，以了解去中心化的Web概念、协议和工具，它遍及四大洲的23个章节。
我们建立了一个新的IPFS文档站点，该站点具有改进的搜索、信息体系结构以及有关行星际概念的解释器。
我们的2019年路线图
为了绘制今年的路线图，我们进行了2019年的大规模规划工作，以写下我们的使命，为IPFS项目定义许多长期目标中的一些，并优先考虑首先将精力集中在哪里。我们有很多“计划中”的债务，因此在项目路线图上从0变为1是一项巨大的工作。我们的流程涉及每个工作组围绕共同目标生成路线图，然后将重要工作流合并为整个项目的“史诗”，以突出我们的主要目标。
聚焦打包管理器
去年，我们的主要目标是通过分析在包管理器中使用IPFS的需求和痛点来提高IPFS性能和可伸缩性。这个目标的重点不是软件包管理，更多的是定义一个有代表性的用例，我们可以研究、测试和推动改进，同时还将使所有具有相似性能和可伸缩性需求的下游IPFS用户受益，以添加、更新和获取大型文件数据集。
专注于包管理器之类的代表性用例，使我们对IPFS改进的优先级有了重点和结构。我们构建了许多概念验证（POC），例如apt-on-ipfs，npm-on-ipfs，clojars-on-ipfs和homebrew-on-ipfs，以分析IPFS在用户对添加、更新的期望方面的表现如何，并获取大型软件包存储库——使我们能够识别并修复主要的痛点。例如，我们的POC确定了将GB的数据添加到IPFS的巨大瓶颈。进一步的测试通过切换到默认的异步数据存储，使添加Linux和OSX设备的速度提高了一倍。IPFS以前需要24分钟添加Arch Linux存储库后，这些修复仅用了11 分钟（与复制/粘贴时间相比）。注意：在Bader数据存储上看到的改进，已经比flatfs快3倍。
我们的打包管理器目标还帮助我们集中了用户研究、季度目标和协作。在第一季度和第二季度，我们的打包经理团队调查了空间，并确定了打包经理仓库中记录的核心需求。这些见解为我们的OKR季度计划和驱动功能提供了信息，从而使在IPFS上镜像文件系统包管理器变得更加容易。一个特别的附加功能是在“最后更新”时间向我们的unixfs数据模型添加元数据，以支持更智能/更快的软件包更新（简称为unixfsv1.5，已在js-ipfs中实现）。其中许多针对包管理器的改进都将在我们的下一个功能版本go-ipfs 0.5.0中推出——请随时关注或抓住最新的版本来尝试一下。
我们还与IPFS用户建立了合作关系，以合作伙伴改善包装管理用例的IPFS。我们与Netflix的主要合作之一是使用我们的点对点数据传输算法Bitswap优化获取大型容器图像的速度。您可以在我们即将发布的博客文章中了解有关该特定协作的更多信息以及由此带来的Bitswap性能的提高。
IPFS群集还发布了协作群集，这是一项新功能，使程序包管理器维护者和镜像程序可以跨IPFS节点社区添加和复制存储库。借助协作集群，任何维护者都可以将新的更新推送到要镜像的数据引脚集，然后在所有镜像节点上进行分片和同步。我们已经看到像Pac-Man这样的包管理器以及许多“数据包管理器”（如Wikipedia和Project Gutenberg）已添加到协作集群中。
我们如何违背打包管理器的目标
今年，我们在许多程序包管理器社区所需的大规模性能方面取得了长足的进步，但是很明显，要实现广泛采用并满足更多类型的程序包管理器的需求，还有许多工作要做。尽管专注于特定用例确实有助于我们识别和推动重要的修复，但它没有为我们在整个IPFS生态系统中提供反馈意见，即哪些痛点是阻碍增长或增值的重中之重。我们还发现，在软件包管理器中增加IPFS使用率的许多方法实际上与我们要实现的核心目标不同：使IPFS本身更好。这种紧张需要持续保持警惕，以确保许多下游用例（不仅仅是专用的软件包管理器工具）都能感觉到功能和改进。
最后，我们成功地保持了专注，没有建立另一个新的程序包管理器，而是获得了大量功能和改进，以使IPFS更好地为每个人所用。我们没有成功的地方是将这些改进直接交付并集成到现有的程序包管理器中，以通过敬业的、有才华的开发人员社区来推动IPFS的采用和可见性。借助go-ipfs 0.5.0中的功能和改进功能，未来的采用工作将大为畅通，但是我们还通过研究了解到，由于半发行版，许多软件包管理者社区并不很快采用围绕软件包分发的新工具维护的无偿性质。
为了支持更慢、更临时的采用节奏，我们计划使用DevGrants等渠道和协作以支持在自己的社区中行动的软件包管理者采用者。这使我们能够继续将我们的核心工作组集中于改进和扩充核心协议和参考实现，同时支持许多社区应用程序和这些工具的完善。
