文章转载自OReillyData，ID：OReillyData，作者：Fernando Pérez
在本文章里我们会着眼于Jupyter项目回答下面三个问题：
1.为什么这个项目会存在？也就是说，我们的动机、目标和愿景是什么？
2. 我们是如何发展到现在的状态的？
3. 从Jupyter自身和它所处的数据和计算的大环境看，接下去它会关注于什么事情？
Jupyter项目旨在提供一套开源工具的生态系统来方便交互式计算和数据分析。在此分析中，人直接参与到计算的循环（通过执行代码来理解一个问题，并迭代式地改进他们的方法）是Jupyter项目最主要的考虑。
围绕人来定位Jupyter是整个项目的关键。这帮我们在某些方向上限定了范围（例如，我们不会开发一个通用的图形用户界面框架），同时在其他方面进行了泛化（例如，我们的工具是编程语言独立的，尽管我们团队有非常强的Python背景）。为了满足这一目标，我们：
1. 试图去获取人在使用计算机去理解和推断数据、模型和算法过程中的本质，并为此来探索想法和开发公开的标准。比如，这就是Jupyter消息协议和notebook文件格式为了它们所针对的问题所提供的功能。
2. 开发构建能支持一个生态系统发展的库。在这里的工具可以很好地交互，而不用每个人自己再去“造轮子”。例子包括创建新的Jupyter kernel（执行用户代码的组件）的工具，或者把notebook转化成其他文件格式的工具。
3. 开发终端用户应用程序，将这些想法应用于科研、教育和工业界中反复重现的日常工作流程。这是一系列的工具，包括从现在值得尊重的IPython命令行shell（其正在不断发展和改进中）以及我们广泛使用的Jupyter Notebook，到诸如为机构准备的JupyterHub等新型工具，以及我们下一代JupyterLab模块化和可扩展接口。 我们努力构建高可用性、非常高质量的应用程序，但我们更专注于具体的使用模式：例如，JupyterLab的架构主要针对Web-first方法进行了优化，而目前我们生态系统中的其他项目则针对个人计算机桌面使用，如开源的nteract客户端或在商业化的PyCharm IDE中支持Jupyter Notebook文件。
4. 提供一些服务来方便Jupyter工具的采用和使用。例子包括NBViewer，我们的一个在线notebook文件共享系统，以及一个免费的演示服务：try.jupyter.org。 这些服务本身是完全开源的，使其他人可以在自己的环境中部署它们，也可以基于它们构建新技术，例如这个mybinder.org系统。该系统提供一键式部署的GitHub存储库，用来存放自己的代码、数据和notebook文件。以及这个GitHub上的Jupyter Notebook文件的原始渲染器。
一路走来的一些关键点
这里不是要做一个详细的历史回顾展。相反，我们将重点介绍一些里程碑，它们展示了与现在继续相关的一系列重要的观点是如何产生的。
交互式的Python和科学Python生态系统。Jupyter是从IPython项目演变而来的，专注于使用Python进行交互式计算来应对科学计算的需求和工作流程。从2001年开始，IPython就在道义上承诺构建一个完全开源的项目（从而让研究结果可以无障碍地被共享），并且认识到Python的特性可以使其成为学术界中那些收费的计算软件的挑战者。这意味着IPython会与科学Python生态系统一起成长，为使用NumPy、SciPy、Matplotlib、pandas和其他功能强大的工具包提供“入口”。因此从一开始，我们发现了一个很好的分工：IPython可以专注于人机交互的问题，而由其他项目提供数据结构、算法和可视化等。各种项目通过一个共同的许可证结构自由共享代码，使每个项目能够增加自己的内容的同时，一起为最终的终端用户创建强大的系统而提供各种工具。
开放的IPython Notebook协议和文件格式。2010年左右，在为IPython构建notebook进行了多次实验后，我们朝着今天所建立的架构迈出了第一步。 我们希望保留“IPython体验”的设计，这意味着IPython终端的所有特性和工作流都会被保留，但它将通过网络协议进行操作，以便不管客户端在哪里，它都可以连接到提供计算的服务器。使用ZeroMQ网络库，我们定义了一个协议来捕获我们在IPython中熟悉的所有操作，从执行代码到自动补充完成对象的名称（内省操作）。这一决定，在随后的一年多一点的时间里，带来了在2011年夏季发布的图形客户端（仍然使用的Qt控制台）和Jupyter Notebook（那个时候的名子还叫IPython）的第一个迭代（更多的细节可以在这篇博文中找到）。
从IPython到Jupyter。 IPython Notebook被SciPy社区迅速采用，但很快大家就很清楚地发现它的底层架构可以用于任何交互式的编程语言。随后在很短的时间内，除Python之外的其他语言（Julia、Haskell、R等）的内核就被连续地创建了出来。我们自己开发了一些，但大多数内核都是由这些语言的用户独立开发的。这种跨语言的使用场景迫使我们去仔细地验证我们的架构，以消除它对IPython的任何意外依赖。并且在2014年，这也导致我们将该项目的大部分重命名为Jupyter。这个名字的灵感来自Julia、Python和R（数据科学的三种开源语言），但这个名字代表了超越了任何特定语言的通用思想：即计算、数据和人类的理解、共享和协作的活动。
从今天的观点来看趋势
把Juypter带到这一步的这些想法已经编织成更大的计算和数据科学的框架，我们预计它未来将会产生重大影响。以下是我们在Jupyter生态系统中看到的六个趋势：
1. 交互式计算已经是一件真实正经的事情。面向数据的计算已经向更多的从业者展示了交互式计算的想法。科学计算领域的人们已经通过Matlab、IDL和Mathematica等程序语言熟悉了这种人机交互式的计算。然而，当我们在二十世纪初期开始开发IPython时，这种工作流程对于传统软件工程领域的开发人员而言还是很陌生的。诸如Python和Ruby之类的语言提供了交互式的shell，但它们的功能有限，只是轻量级的实验项目，而不是首选的开发环境。
当IPython的第一个版本在2001年出现时，它就试图使Python的交互式计算对于那些全职用Python的人来说是愉快的。诸如Jupyter、RStudio、Zeppelin和Databricks等工具已经进一步推动了基于Web的交互式计算。从而使数百万统计学家、数据科学家、数据工程师和人工智能/机器学习人员每天都在进行交互式计算。传统的集成开发环境（IDE）正在被交互式计算环境所取代：Jupyter、JupyterLab和RStudio是这一趋势的杰出例子。与交互式计算共同发展的是基础模块的形式化、被识别和开发出来：内核（运行代码的进程）、网络协议（正式的消息规范来发送代码到内核并获得结果）、用户界面（提供与内核的人机接口）和基于MIME的输出（除简单文本之外的任何类型的结果的表示）等。
2. 计算型叙述被广泛地创造出来。实时运行的代码、叙事性的文本和可视化被整合在一起，方便使用代码和数据来讲述故事。在书籍、博文、同行评审的学术出版物、数据驱动的新闻等不同用户和业务场景下，这种计算型叙述正在被用于制作和分享技术内容。诸如Jupyter Notebook和R Markdown等文件格式将这些计算型叙述编码成可共享和可重现的单位。然而，计算型叙述的实践已经远远超出了这些开源的格式，扩展到许多交互式的计算平台。
3. 为具体的洞察编程而不是泛化的任务。计算机科学的总体目标是泛化和抽象。软件工程专注于为多种问题设计统一的库和应用。随着交互式计算作为一种实践的兴起，并将这一过程纳入计算型叙述（我们称之为Literate Computing），我们现在有一个新的人群，他们使用编程语言和开发工具的目的不一样了。他们通常为非常具体的目的来探索数据、模型和算法，甚至可能在单个数据集上花费巨大的努力，但会提出复杂的问题并找到可以共享、发表和扩展的见解。由于数据普遍存在于各个学科领域，这表示编程语言和工具的受众群体会极具扩张，但是这些受众的需求和兴趣与“传统”的软件工程师的需求是不同。
4. 拥抱多种语言的个人和组织。在处理数据时，许多个人和组织认识到利用多种编程语言优点的好处。在一个以数据为重点的研究组或公司中，看到Python、R、Java和Scala都被使用的情况并不少见。这迫使大家开发和构建协议（Jupyter消息规范）、文件格式（Jupyter Notebook、Feature、Parquet、Markdown、SQL、JSON）和用户界面（Jupyter和nteract）等这些可以跨语言统一运行并最大化互操作性和协作的工具。
5. 交互式计算的开放标准。十年前的业界重点是为互联网创建开放的标准，如HTML、HTTP及其相应的设备。今天，我们看到为交互式的、面向数据的计算开发的相同类型的标准。Jupyter Notebook文件格式是用于计算型叙述的JSON文档格式的正式规范。Markdown是叙事文本的标准（虽然是有点狡猾）。Jupyter消息规范是允许任何交互式计算客户端与任何语言内核通信的开放标准。Vega和Vega-Lite是用于交互式可视化的JSON模式。这些开放标准使得大量的工具和语言可以无缝地协同工作。
6. 有意义的共享数据。政府和组织的开放数据计划为普通人和机构提供了丰富的数据来源。这些数据可被用于探索、再现之前的实验和研究，以及为别人构造服务。但是数据只有在配合正确的工具（Jupyter、nteract、RStudio、Zeppelin等）后才有意义，才能让用户可以探索这些数据集并分享其结果，能将把数据分析过程人性化，能支持协作，以及能用叙述性内容和可视化来展现数据的意思。
那么接下来的问题就是：所有这些趋势是否意味着一种更大的模式？我们认为它们都预示着为了优化人机交互和理解所进行的计算的代码、数据和用户界面的出现和发展。
过去，人类不得约束自己以适应计算机的各种限制（网络、内存、CPU、磁盘空间等）。现在这些先前的约束已经显著地得到了放松，我们可以享受使用高级语言（Python、R、Julia）和丰富的网络接口（Web浏览器和JavaScript框架）。我们可以使用精心设计的基于浏览器的用户界面构建出强大的分布式系统，使我们能够使用计算资源和数据，而不管它们所在的地理位置是哪里。我们现在可以开始优化我们最重要的资源：人的时间。
先前这些的约束放松并没有神奇地触发以人为本的计算系统的创造，但是打开了它的大门。真正的动力可能是每个可以想像得到的组织和活动里出现的数据的爆炸式增长。这使人们深刻地需要以更重要和有意义的方式与代码和数据进行交互。如果没有这个动力，Jupyter项目也依然会存在，但它可能只会局限在非常小范围的学术科学计算社区里。
组织机构需要在制定数据战略时开始关注人的因素。Jupyter能在一些机构中取得的巨大成功并不是高层管理人员做出的购买决定。它是那些每天都要必须花时间纠结于编码和数据的开发人员和数据科学家自己的决定。在未来，把人的因素放到前沿和中心，并把设计和可用性与性能一样优先考虑的工具和系统才将会被实际使用和广泛采用。我们开发了Jupyter的思路是因为我们自己想使用它，而我们将基于这些想法继续前进。
致谢
在此，我们无法一一感谢所有那些让Jupyter成为可能的人，但是我们想统一感谢你们所有人：用户、开发人员和与我们互动的许多社区在线论坛和活动的参与者。无论您是高中教师、音乐学家、癌症研究员，还是为公司构建数据科学工具的开发人员，这个项目首先并会继续服务于一个公开分享的想法、工具和素材的世界。从我们的长期开发人员到把这一工具带给你的新同事的人员，感谢你们参与这个项目。
如果没有下述慷慨支持我们的机构，Jupyter是不可能的存在的：Alfred P. Sloan基金会、Gordon和Betty Moore基金会、Helmsley慈善信托基金会和Simons基金会。最后，我们要感谢为项目提供资金、资源和开发工作的行业合作伙伴：Bloomberg、Continuum Analytics、Enthought、Google、IBM、MaxPoint Interactive、Microsoft、Netflix和Rackspace。
我们要感谢Jamie Whitacre和Lisa Mann对这篇文章所做的宝贵贡献。
