Fernando Pérez (@firstname.lastname@example.org) is an Associate Professor in Statistics at UC Berkeley and scientist at LBNL. He builds open source tools for humans to use computers as companions in thinking and collaboration, mostly in the scientific Python ecosystem (IPython, Jupyter & friends). A computational physicist by training, his research interests include questions at the nexus of software and geoscience, seeking to build the computational and data ecosystem to tackle problems like climate change with collaborative, open, reproducible, and extensible scientific practices. He is a co-founder of Project Jupyter, the 2i2c.org initiative, the Eric and Wendy Schmidt Center for Data Science and Environment at Berkeley, the Berkeley Institute for Data Science and the NumFOCUS Foundation. He is a recipient of the 2017 ACM Software System Award and the 2012 FSF Award for the Advancement of Free Software.
This is an important year for Jupyter, as we have revamped our entire governance model, looking to give us a solid foundation for another 10 or 20 years of growth (counting from the start of IPython back in 2001). We discussed that transition in a separate talk - here I would like to reflect from a personal perspective on a few aspects of the project.
As part of this transition, I stepped down as "project BDFL". This was a decision driven by many reasons; among others, I think the context of open source communities today is radically different from 20 years ago, and our view with Jupyter is centered around a multi-stakeholder community, where no single actor should concentrate too much authority. From day one, IPython, then Jupyter, were collaborative efforts. Many people put in their ideas, code, feedback and energy to create something we can all collectively own, adapt for our needs, and extend in new directions. While it's necessary to build a sense of vision and direction for any project to be successful in the long run, a "dictator" is entirely the wrong metaphor to base that work on. Python itself has moved on from that model, and we hope more projects will continue to find better ways to harness the energy of their entire community.
The space where Jupyter exists today is challenging: we have had phenomenal success on many fronts. From users of Juptyer itself to those who build on our foundations, standards and protocols in new directions, the impact of the project goes far beyond our original hopes and expectations. But, as well stated in the classic Innovator's dilemma, this type of large-scale success is itself a potential trap. While not a commercial entity, Jupyter still needs to provide value to all of its stakeholders, with the added challenge that its own strategic directions are not decided by any single actor.
This conference is an opportunity to learn from each other on both what has worked so far, and how the next decade will be very different. If we are to continue providing value, these are some of the challenges I hope we'll tackle together:
- Jupyter beyond the "Global North": Jupyter should be a tool for democratizing access to science and education, but in a way that empowers all to participate, not only to access and consume. This means we need to continue growing our community of developers, contributors and leaders in countries beyond those most traditionally represented (which for Jupyter, is highly concentrated in the US and Europe). Important efforts have made progress on this front already, but we should make it a priority to build culturally-relevant, contextually appropriate spaces for local communities to develop new tools and use cases, as well as contributing back into the main project.
- AI: as of this writing, 2022 is shaping up as a watershed year in AI, with advances like ChatGPT causing ripples in the industry and even general media. These tools open a new front on the idea of "interactive conversations with humans and the computer" that Jupyter has already explored. They also tend to be developed and controlled by a few large and powerful corporations. Jupyter should explore its own version of how to ensure these tools can empower everyone, while innovating with use cases that capitalize on our architecture.
- What are the layers of the "core of Jupyter" that its stakeholders should agree upon, and continue building as 100% open-source, vendor-independent technology, while so many of these stakeholders have their own business goals? These goals often depend on Jupyter-based products, so there is an inherent tension between what goes into the "Jupyter commons" and what is the value added by a specific vendor. Rather than wishing this tension away, we should recognize it and work productively within these constraints.
To explore these and related questions, we should reflect on identifying the scope of Jupyter - Jupyter tools cover many different aspects of computing, yet there's a common theme. I'll present my own take on this, informed by my interactions with many of you for 20+ years, in the hope that it can lead to useful conversations for our next period.
I hope this talk will be a useful point of reference for some of the ideas that the project has built so far, but focused on thinking of the future. While I will discuss them from my limited, personal perspective, my goal is to motivate thinking at the strategic, community and technical levels.