Here at Quantopian, we love the community that has formed around our open source software (OSS) projects. As our OSS has found its way into personal and professional uses, the demand for maintenance has increased. This is the proverbial good problem for OSS -- popularity creates maintenance work and even though the software is free in every sense of the word, OSS users are sometimes more demanding than paying customers.
We believe quant finance needs OSS standards for critical functions like factor analysis, backtesting, and metric calculation. So, one of our 2020 resolutions is to adapt to the higher maintenance demands on our popular projects!
First, a little history. In the past, we have tried to explicitly prioritize individual OSS maintenance tasks against our internal roadmap. Because we were comparing support/maintenance of OSS with projects that generate revenue, we were consistently de-prioritizing OSS work. The product and engineering team recognized that this process was leading us toward a tragedy of the commons. As the primary maintainers, we needed to find a better way to invest effort in our projects.
Our product and engineering team came up with a new approach: weekly time allocated for OSS work. This time is booked into our engineering plan, but independent of our normal feature prioritization process. The idea is to protect this time for healthy maintenance of our OSS projects.
To start, we have been working through issue tracking/communication backlog. Hopefully, you have noticed an uptick in this basic communication! Our short-term goal is to get a firm handle on the state of the projects (we will be splitting our time across Zipline, Alphalens, Qgrid, and the rest of our OSS projects).
We aim to be more timely and more clear about requests to our OSS projects that we do not consider high priority and do not plan to support ourselves or through community PRs. We will do our best to be clear about our reasoning and we welcome your feedback.
Besides priority, we will also consider whether we can practically accept a community contribution for a high priority OSS project goal. We see a split where some goals are easily separable and therefore feasible/convenient for us to accept contributions. We will try to communicate early and clearly whether we can accept community contributions for a particular goal.
Once we have a handle on backlog issues, we will increasingly focus on moving the projects forward. An example is adding support for the most recent Python versions in Zipline. We have shipped that work for the Quantopian platform, and we look forward to bringing it to Zipline.
We want to have a more clear framework for work that we feel we need to do at Quantopian and work that is a match for community contributions. Going forward, we think the key criteria for a healthy community contribution is work that is cleanly separable and independent from Zipline’s installed base and Quantopian’s internal dependencies. Here’s a discussion on a few maintenance priorities for Zipline that illustrates our thinking.
Here’s to more OSS in 2020!