文章轉載自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對這篇文章所做的寶貴貢獻。