Attribute: Open

Overview

Openness is built into the project at a deep level. This attribute builds a dedicated and invested community of users and developers that have good feelings about the project. Openness also builds trust, accountabilty and integrity. It blurs the line betweeen users and developers by providing a single community that spans all project activities.

Open source

The IPython source code is released under the terms of the BSD license. This license allows any individual or legal entity to use the software, without restrictions, for any purpose, commercial or otherwise. Companies are building commercial products based on IPython:

• Wakari by Continuum Analytics
• Anaconda by Continuum Analytics
• Canopy by Enthought
• PiCloud

A wide range of open-source projects and scientific collaborations also build on top of IPython.

Other open-source licenses, such as the GPL are more restrictive and would not allow for this extended ecosystem to grow and flourish.

Open process

The entire development process of IPython is carried out in the open:

• All contributions undergo public code review using GitHub Pull Requests.
• All Issues are reported and discussed publicly through GitHub.
• All real time discussions are done using public HipChat rooms (nice, web-based IRC chat).
• We maintain a public Roadmap that describes where the project is headed.
• We hold weekly "lab meetings" on Google Hangouts to discuss the project with core developers, users and guests. The minutes and agenda for these meetings are maintained on a public Hackpad. These meetings are broadcast publicly and recorded.

We have found that an open process doesn't happen automatically:

• It is really tempting for developers, especially those in close physical proximity, to rely on private discussions.
• We try to minimize these private discussions as much as possible, but they do still happen.
• We always try to post the results of private discussions on our mailing lists or GitHub.

Open standards

It is really easy, and sometimes tempting, to invent your own:

• Serialization format
• Domain specific language
• Network protocols
• Document formats

As much as possible, we try to use established, open standards:

• Notebooks documents are just JSON data and can be read in any language with a JSON parser.
• The actual data stored in the JSON document is also in open standards (HTML, Markdown, PNG, JPEG).
• The Notebook is styled using CSS
• Our message architecture is built on top of JSON, ZeroMQ and WebSockets.

In a few cases we have had to invent our own standards on top of these base standards:

• Notebook format (how exactly we store data in the JSON).
• Kernel message architecture.

We are attempting to make these standards documented, tested, versioned, etc. The broad adoption of the IPython Notebook by other language communities would not be possible without this openness.

Styling