When was the last time you used a third-party package in Python?
Have you recently pip installed SQLAlchemy?
Maybe you looked up the documentation on a package you found in PyPI?
These two core pieces of infrastructure involved are both freely available and open source,
PIP and PyPI, as well as read the docs.
How are these funded?
How well are they funded?
It turns out that we are not doing a good job sustaining the underlying infrastructure
in the Python ecosystem.
This week, you'll meet four panelists for a discussion on the problem and its solutions.
Donald Stuff from PyPI and PIP, Eric Holscher, co-founder of Read the Docs, Carol Willing,
director of the Python Software Foundation and Project Jupyter core developer, and Eva Jalaska,
director of operations at the Python Software Foundation.
This is Talk Python to Me, episode 84, recorded October 31, 2016.
Developers, developers, developers, developers.
I'm a developer in many senses of the word, because I make these applications, but I also
use these verbs to make this music.
I construct it line by line, just like when I'm coding another software design.
In both cases, it's about design patterns.
Anyone can get the job done.
It's the execution that matters.
I have many interests.
Sometimes...
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the
ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at talkpython.
This episode has been sponsored by Rollbar and GoCD.
Thank them both for supporting the podcast by checking out what they're offering during
their segments.
Hey, everyone.
I'm honored to be sharing this important conversation with you.
Thanks for listening to this episode and all the others.
The community response to this podcast and my online courses has been simply amazing and
humbling.
You've encouraged me to dedicate some more time and energy to the project.
So before we get to the panel discussion, I want to tell you about a new project I'm launching
today, November 8th, 2016.
I'm launching a new second podcast called Python Bytes.
You can find it at pythonbytes.fm.
That's pythonbytes.fm.
Please take a moment to listen to the first episode and provide feedback.
The goal of the show is to deliver timely Python developer headlines directly to your earbuds.
I'm co-hosting the show with Brian Okken of Test and Code Podcast fame.
We try to keep this short and sweet.
So this show should be about 15 minutes per episode.
So please check it out at pythonbytes.fm.
Now let's talk about funding Python's open source infrastructure.
Hey everyone, welcome to Talk Python.
I'm really excited to have you here to talk about this pretty important topic of funding
open source infrastructure and some of the things that are actually the underpinnings
of the Python ecosystem itself.
So welcome.
Let's get started with a quick introduction.
Got four of you on the show this week and that is really excellent.
I think it's going to give us a lot of perspectives.
So I'd like to start with what's your background?
Why are you particularly passionate or interested in Python's open source infrastructure in particular?
And Carol, let's start with you.
Hi, thanks, Michael.
I am Carol Willing.
I am a director of the Python Software Foundation and also a core developer on Project Jupyter at Cal Poly.
I have a background in econometrics and economics as well as engineering.
And I really care about the infrastructure because it supports so much of what we do in education,
whether at the university level or on the K through 12 level in the states as well as globally.
Yeah, excellent.
It's super important education.
I think one of the great growth areas of Python and a lot of interesting new projects and people are coming into it is coming from academics and from the data science space.
And so that's right, right in there.
Eva, how about you?
My name is Eva Jalowska.
I am the director of operations at the Python Software Foundation.
Even though I do have a little bit of technical experience, all of my Python involvement has been community related.
I did get involved with the PSF as a third party meeting planner working on PyCon.
And that started in 2008.
In 2011, I did a career shift and joined the PSF exclusively to work on PyCon and other foundation activities.
In mid-2015, we began to hire additional staff.
And at that time, my role evolved to director of operations.
And even though PyCon is still a responsibility of mine, I now concentrate more on managing our staff and foundation sustainability,
which includes everything from how we internally operate to how we can best serve the Python community.
And that is why Python infrastructure is important to me.
All right.
Excellent.
Eric, how about you?
Yeah.
So I'm Eric Holscher.
And folks on this podcast probably know me most from kind of the work I do around read the docs.
And so I think, you know, both Donald with PyPI and myself are in a very similar position where we're running kind of large infrastructure.
infrastructure projects that don't have or they don't necessarily feel like they have the largest amount of community support.
And I think we're trying to kind of raise awareness around how that might be an issue going forward.
And so there's definitely kind of a selfish motive for kind of having my own work be funded better and more supported,
as well as kind of being able to build things like this within the community and kind of setting examples of models.
So if people want to build more infrastructure to support the community, there is actually a model for making that sustainable so more of it can happen.
I think that's kind of my angle on it.
Yeah.
Okay.
Great.
Thanks.
And Donald, you were on episode 64 and you shared a lot of the work that you've been doing with PyPI.
But go ahead and tell everyone about yourself for this episode.
Yeah.
So I'm Donald Stuff.
And, you know, I work on PyPI and pip and sort of Disutils, the sort of related projects for Python's packaging story.
In that regard, I run operations for PyPI and I'm sort of the primary developer and operations on both PyPI and PIP.
There are other people who will help out.
But as I was currently being paid my time for that and that enabled me to spend a lot more time than other people were able to.
I suppose it sends a little bit of a mixed message about whether the project needs help if there's somebody whose full-time job is to work on an open source project, right?
Like PyPI.
What do you think?
It's sort of a dangerous place to be in.
I mean, full transparency, I was just laid off from my job.
So I am no longer employed full-time to do that.
And it's dangerous because now that I'm laid off, all of a sudden we just lost the only full-time employee working on that project, which is a huge loss of hours available to dedicate to different resources in that space.
Yeah.
And that whole experience, you talked about it on Twitter and saying it was not like HP decided they were going to defund PyPI or anything like that.
It was just, you know, HP is going through some challenges.
They laid off a bunch of people and it just so happened they, I guess, felt like this funding for PyPI didn't really match with what they were doing anymore.
And I want to be really clear to everyone listening that this is not to throw HP under the bus, right?
Like HP was doing more than any other company out there to fund PyPI.
The fact that they, like, stepped back to being on par with the other companies is unfortunate, but it's not like we should be unhappy with HP.
It's more like, well, wait a minute.
Why did we have just this one company that happened to, like, more or less donate an employee to run the most important way that libraries are shared in Python, right?
Yeah.
And, you know, as far as I can tell, they actually didn't even know they were defunding PyPI.
Yeah.
You know, this is a fairly large scale layoff and my entire team got dissolved.
So as far as I've been told, you know, I just got caught in a large net and there was no sort of knowledge that PyPI was even a thing at the level that this was being taken place of.
Yeah, absolutely.
So I, you know, you and I spoke for an hour on episode 64 about Python packaging and what PyPI is, among many other things.
But let's start this conversation by kind of laying out the elements that are in play here.
So, Eric, you talked about read the docs.
We've talked about PyPI.
But, Eric, what other stuff do you think is under this banner of open source infrastructure and the Python ecosystem?
I mean, I think those are the two big projects.
I think also kind of the Conda ecosystem around scientific Python is another place.
I think a lot of it is, at this point, kind of companies.
So things like, you know, Travis CI is a huge point where a lot of the open source infrastructure is built on that.
And they've actually been building a sustainable business around that.
But I think if, you know, if Travis CI went away tomorrow, that would have huge impacts on kind of the Python developer ecosystem.
Yeah, and really just kind of all that entire kind of suite of developer tools that people are kind of using on their day to day.
And, yeah, but I think in terms of kind of Python specifically, I think, you know, pip and, you know, PyPI are the most obvious.
And I think read the docs and other just tools that developers are using.
And, you know, maybe someone else will have a better kind of more encompassing answer.
I think, you know, in some regards, kind of Twitter and GitHub, right, are also both in that basket where we have these massive corporations running these for us for free.
And that's very much infrastructure we depend on.
But, you know, that's a little bit less precarious because they are building kind of businesses around them.
But there are some other issues with that, for sure, as you see, maybe with something like NPM being the kind of most analogous to PyPI.
Right.
Yeah, and NPM does apply to Python developers.
There's a lot of tools that you get from NPM as well as anytime we're building web frameworks, we probably want to go get some JavaScript stuff as well just for the front end work.
You know, I think, first of all, one of the things I would like to discuss or sort of point out that you guys might not, people who are listening might not realize, is the scale of the cost of some of these projects.
So for PyPI, Donald, obviously, you were being employed to work on it and there's your time.
But there's also actual infrastructure expenses.
And luckily, from what I understand, those are still being covered by places like Rackspace and so on.
But for PyPI, you said last May we had 340 terabytes of traffic and that was roughly $35,000 a month in infrastructure expenses, right?
Yeah.
Yeah, so we've now gotten to the point where I believe the last 30 days we've hit 390 terabytes of bandwidth.
So we're starting to push closer to $40,000 a month in donated services.
That's what the cost would be if we actually paid for that.
We are very lucky that we have a Fastly Rackspace Dream host.
I can't list them all.
But there's eight or ten different companies that donate those services to us.
But yeah, it's a significant cost without those donations.
We would not be able to bear the cost of doing that.
Yeah.
Even a very happy donor couldn't – very unlikely that they could handle that much of an expense on a monthly basis.
Eva, what do you think about funding some of these projects?
Like where's the current funding coming from?
You know, Donald talked a little bit about HP and the guys donating at Rackspace, donating bandwidth and to the other companies as well.
But where else does funding come from?
So most of it, as already everyone mentioned, is through in-kind sponsorship.
So everything from server providers, CDN management providers, search optimizers, et cetera, even to design work.
For instance, if you look – I know that Donald said he couldn't list all of them.
But if you look at the bottom of pypi.org, you can see all the logos of the donated services that Donald has received.
Obviously, the main one has been HP employing Donald.
And we also make up a lot of that through volunteer time.
We have a lot of volunteers that work and put a lot of time into making it happen.
And up to March of this year, the PSF infrastructure was completely managed by volunteers.
And then in March, we decided to hire an IT manager who is slowly gaining his bearings around the ecosystem.
The PSF does fund a little bit.
We do, for instance, maintain domains and things like that and other random charges.
Sometimes it happens for certificates or things like that.
But we do have, for instance, other – and I wanted to kind of go back a little bit because there are a lot more infrastructure than just dev tools, in my opinion,
especially since we do a lot of the day-to-day foundation stuff like mail.python.org or even our wiki.
That's, I guess, more internally used.
But I have an example.
For instance, for mail.python.org, last year, the server went belly up.
And this was before we had our IT manager.
And when you're in peak PyCon sponsorship sign-up time and you don't have mail for four days, that could be a very extreme thing.
So it actually took us four days, including the weekend, to be able to restore it.
And we had to search down volunteers who were no longer active and that had – we had to find who had backups.
But I can't help to wonder, like, what if those volunteers weren't available that weekend?
What would we have done?
So it's kind of questions like that that makes us really think, how can we improve the funding?
Yeah, so there's the keeping the organization running, and then there's the public-facing stuff like PyPI and read the docs.
Yeah.
Any other funding, Carol, that you can think of?
Other things that we should maybe throw under this?
What is open source infrastructure for the Python community?
Yeah, I think that there's key infrastructure that, you know, have a fixed cost that, you know, a lot of our sponsors have very generously given us time or services in order to have even the base technology to run things on.
And then if you look at the team that's in place from an infrastructure standpoint for just running the Python Software Foundation, it's like a hugely leaned startup with Eva and her crew running a 24-7 global organization pushing around terabytes of data and with volunteers largely being the staff that gets things done.
And, you know, my concern is to be able to sustain the fixed costs of the infrastructure over time, but also be able to have some variable resources that are funded so that we're not burning out volunteers.
I mean, Donald was very generously funded by HP, but his time and effort went far beyond just his salary for the day.
And, you know, we all owe him a huge thank you for that.
And the same with Eric on Read the Docs.
It's a labor of love as well as a key part of our infrastructure, as is PyVideo.org, our user groups, being able to fund scholarships for us to grow the community.
So I think infrastructure really sort of touches everything that we do.
Yeah, that's a really interesting view.
I just interviewed Paul Logsdon from PyVideo, and that's coming out of the week of this one being recorded.
So that's a really interesting one as well.
Eric, can you speak to Read the Docs a little bit?
And how, you know, what's the expenses?
How do you guys keep that running there?
Sure.
Yeah.
And just to kind of follow on quickly with Carol's point, I think, yeah, like the staff of PyCon as well is just this amazing, like this unreasonable, amazing outpouring of love from the community.
And all of that staff is volunteer, except for, you know, a few people at the top, but the hours that go into running events like that.
I mean, I have my own conference night, I know.
So, yeah, there's so much work that we all depend on as a community.
But, yeah, so anyway, the costs of Read the Docs, similarly, are paid for by Rackspace.
I think Rackspace is like one of these people where if their sponsorship of open source and the Python community as well went away, these massive things.
I know, like the cryptography project that's doing a bunch of really good crypto stuff.
I mean, there's so many backbone kind of CI tools and servers and all these costs of all of the projects around the Python ecosystem that Rackspace is putting the bill for.
And if that ever went away, there would be a huge kind of scramble, I think.
And that's another just huge piece of infrastructure, all these servers, everything's running on.
Our recent bill from Rackspace was, I believe, $3,600.
So we keep our server costs incredibly low for the amount of things that we're doing.
I think we do about 25 million page views.
I think we push close to 10 terabytes of data.
But mostly we're serving static files.
So we have a very kind of low cost of infrastructure based on the – and a lot of that was architectural decisions that we made because we knew the funding environment that we were existing within.
So everything is very lean.
Yeah, similarly, the main cost is people.
Operations person who's wearing a pager to make sure the Python community's documentation goes down has a market rate of easily $100,000 a year, at least within the U.S. kind of pay scales.
And so that dwarfs the, what, $40,000 to $50,000 that we would pay in pure infrastructure costs.
But that said, if Rackspace did go away, that would be a huge – there would be a huge scramble for us to kind of cover that cost.
Yeah.
You mentioned GitHub, and if it went away, there would definitely be terrible disturbance in the forest sort of feeling.
Are there contingency plans for if Rackspace backed up?
Because, you know, this is the common theme, and thank you so much, Rackspace, for being such a supporter, right?
But it's also becoming like a single point of failure.
Do you guys know what you would do?
We've had a few different people offer.
I mean, I think, honestly, the initial step would probably be to stop doing builds.
Because a lot of the cost of servers is the build infrastructure, and if we just stuck, you know, static files up somewhere, that would be a viable alternative for at least like a week or something.
And, you know, like somebody maybe couldn't release a new library, but the 99% case is still kind of, you know, the old documentation that we host for everyone would still be available.
And I'm sure we could find yet another, you know, donated service.
But kind of the plan B was so scary for so long that it kind of really did spur us to start looking into business models and kind of sustainability on our own, because that was kind of a scary outcome, right?
And I think similar to having one company employ someone to work primarily on a project, I think having one company hosting all of the infrastructure for free, right?
Like it builds this kind of all the eggs in one basket scenario.
And I think there's, like I'd never even really considered Rackspace in that light, but I think if we really took a deep look at our community, we would find we have a lot of our eggs in a very small number of baskets.
And, you know, I think Russ Keith McGee, who's one of the really people that I've been watching talk about this for a while, says, you know, we really need like kind of that diversity in funding and support to really have something that's truly sustainable.
And so I think that that's definitely the path we need to look down is, you know, how do we reduce dependence on these small set of very generous companies and towards something that's more kind of inclusive of the entire community, supporting the entire community?
Yeah, I agree.
I think it's really a positive thing that you guys have write the docs and all the stuff that's starting to take shape as a business there.
Do you want to spend just a moment and tell people about what you're doing to make that a little more sustainable?
Yeah, so we actually, we turned, we built like an official kind of business around Read the Docs two years ago.
The conferences are actually a completely separate endeavor that just kind of are connected through me as a human, which is also its own business, which is also, you know, building into a sustainable, you know, we have, we're going to have similar to Python, have kind of a part time to start operations person.
But with Read the Docs, we basically tried a bunch of different models that everyone's talked about, you know, consulting, support contracts, all this stuff.
And it turns out that kind of like, unlike a database or an operating system, documentation is not mission critical enough within most organizations for them to pay for support contracts, or training or these things, you know, where we're kind of very much a second thought in a lot of development organizations.
And so I think that's been really hampering our ability to use some of the more traditional business models that have worked in open source.
And so we basically fell back on advertising, which is, you know, kind of the one true business model on the internet that works for paid or for free sites, right?
Like every large free website on the internet, especially, you know, if you view Read the Docs as a content publisher, which at the end of the day, we really are, you know, we're very similar to, you know, a newspaper in those terms, right?
Advertising is the model, right?
Like everyone that's reading documentation on Read the Docs is never going to pay us money, even one penny, right?
Like there's so many more readers to writers or maintainers that the only way to kind of manifest value from those very small interactions is to put an ad on it and to have someone pay you for that small amount of attention.
And so we basically set out to build a advertising business model that we are proud of.
And so we're not tracking our users.
We're doing one ad per page.
It's kind of at the bottom of the sidebar, so it's not in your way.
And so we're really trying to kind of build a model that respects users and kind of respects advertisers and can be a win-win.
And so we call it kind of newspaper advertising on the internet, just because it's like, you know, we put a, we know people are here.
We're going to put an image on a page.
Some people are going to look at it and they're going to click it and you're going to pay us for that privilege.
And so we're really trying to kind of build an ad product that we can be proud of.
I think it's really interesting and it's worth talking about because the other business models are really hard.
like how could you possibly ask somebody to like say as a publisher on there to say to pay at least the people who are doing free open source work,
basically as a volunteer on their own project, like having them pay to use the site is like insult to injury because they're trying to write docs for the community for free.
And you're like, well, you got to pay to do that.
You're like, so a lot of the models, like you said, are, are challenging, but luckily both PyPI and read the docs have a tremendous amount of traffic.
So there's a possibility that some kind of ad story does make sense.
Carol, what do you think?
What do you got some ideas around this ad stuff?
Wow.
You know, I think ads probably have a whole range of people's viewpoints on them.
I think I know when read the docs kind of went to the ad model, we had some people that were really for it and some people that were sort of questioning, like, I don't know that I want ads in my documentation.
Personally, like we worked through on the Jupyter project that the ads were subtle enough that we felt like sustaining the ecosystem of read the docs.
And I'm, you know, I spend a lot of time writing documentation as a developer because I think it's so important and critical for onboarding people and for developers to build their skills.
So, you know, I think advertising, it will get you some of the way and obviously all the things that we've done to date were here.
These things are functioning, but oftentimes it feels like you're holding it together with like scotch tape and a lot of goodwill and ongoing goodwill from the sponsors that we have.
So the question is really, in my view, how do you, you know, we're sort of facing like a classic problem in economics where who funds the infrastructure?
Like in a country, the infrastructure like roads, law enforcement, hospitals are largely funded by the government.
And so we're not directly paying for everything.
And I think we see similar things in open source.
Many people benefit from, let's say, PyPI, for example, whether or not they contribute to it.
And so you've got like that classic economics, free riders getting the benefit, but not contributing anything to receive the benefit.
And I'm not sure how you necessarily get that.
Right.
It's so challenging to take it back to like your country analogy.
One of the ways countries deal with that is they come up with toll roads, right?
Or toll bridges or things like that.
And.
Absolutely.
Those.
I personally find all of those things very distasteful.
I don't like.
I used to live in New Jersey and I felt like I would drive like five miles and stop and pay a dime, drive six miles, pay a quarter.
And I was just always at traffic jams paying like such a small.
Like, why couldn't we just add a little bit of a gas tax or something like this that sort of solved the problem instead of trying.
This thing is costing too much.
So we're going to patch a little fee onto it or something.
And I feel like there's some analogies here as well.
Yeah.
I also grew up in New Jersey and I can remember having to pay to actually go to the beach.
You know, you need a little badge on some of the beaches.
You'd have to pay five, ten bucks, whatever it was to actually step foot on the beach, which on the West Coast we think is sort of very strange.
It's very strange.
Yeah.
But I think certainly paying for service is one model.
But I think much like you, I think it's not something that necessarily is attractive to many people.
It benefits those that have money to pay for it versus the general community.
And like you said, it's an annoyance.
So I think there's got to be other nonprofit models that might be better suited.
And I won't profess to know the solution, but something different.
Yeah.
We definitely don't want to bring some kind of model to this whole place that would kill the delight, right?
Kill the joy.
Absolutely.
Yeah.
Because that's something that's really special.
Eva, how does the PSF pay for itself?
The majority of the PSF's budget comes from PyCon.
PyCon is our main expense and it's also our main source of revenue.
My team and I work very hard every year to try to be in the positive after each PyCon, especially since it's so vital to the foundation's sustainability.
That revenue helps us with future PyCon expenses as well as it helps the PSF have a budget for grants that we give out, which do help grow and strengthen the community.
Some of these grants are infrastructure related.
For example, the PSF has given financial support to read slash write the docs.
And we recently even granted our Python packaging work group, which Donald and I are on, a grant to be used as needed.
We want to be able to do more of it, but it is not sustainable for the PSF at the moment to fully support all of these projects.
In addition to the importance of funding the infrastructure that the PSF oversees, we have other operations that need our financial attention.
For example, the grants that the PSF disburses have been increasing approximately $65,000 year on year.
So that is another important aspect I have to consider when planning the foundation's future.
I mean, this is a little bit off topic, but if anyone's interested, I did cover this at PyGotham this year, so we can check it out for more details.
We do have sponsorship support year on year from corporations, but surprisingly, that is a small percentage of where funds come from.
We are hoping to continue to grow our staff, so we are internally working on how we can increase the foundation's corporate support.
My short-term goal is to improve our sponsorship perspectives, for example, by including some targeted traffic data from, let's say, PyPI to give to organizations.
This portion of Talk Python to me has been brought to you by Rollbar.
One of the frustrating things about being a developer is dealing with errors.
Relying on users to report errors, digging through log files trying to debug issues, or a million alerts just flooding your inbox and ruining your day.
With Rollbar's full-stack error monitoring, you'll get the context, insights, and control that you need to find and fix bugs faster.
It's easy to install.
You can start tracking production errors and deployments in eight minutes or even less.
Rollbar works with all the major languages and frameworks, including the Python ones, such as Django, Flask, Pyramid, as well as Ruby, JavaScript, Node, iOS, and Android.
You can integrate Rollbar into your existing workflow, send error alerts to Slack or HipChat, or even automatically create issues in Jira, Pivotal Tracker, and a whole bunch more.
Rollbar has put together a special offer for Talk Python to me listeners.
Visit rollbar.com slash Talk Python to me, sign up, and get the bootstrap plan free for 90 days.
That's 300,000 errors tracked all for free.
But hey, just between you and me, I really hope you don't encounter that many errors.
Loved by developers at awesome companies like Heroku, Twilio, Kayak, Instacart, Zendesk, Twitch, and more.
Give Rollbar a try today.
Go to rollbar.com slash Talk Python to me.
Donald, have you considered any other models like what Read the Docs is doing or anything for PyPI?
I mean, you do have a tremendous amount of traffic there.
Yeah, so I considered ads briefly.
We didn't need them yet, so I kind of put it on the back burner because I do think people have sort of a – ads are polarizing.
And the less I get yelled at, the better.
Yeah.
But there are other things we've talked about, like the ability to host private packages on PyPI and pay for that privilege.
But then that starts to get into more questions like, well, if we start turning PyPI into sort of a business but still a nonprofit,
are the sponsors that have been donating resources to us, how are they going to feel about that?
Are we going to suddenly look at having to pay $40,000 a month if we start doing that?
So it's sort of like walking a bit on a tightrope wanting to not do something that's going to make these people feel like they're investing or donating to a business.
Yes.
While still being able to try to be more sustainable.
That's a very careful balance.
And I think it's tricky, right?
And I don't want to make this conversation all about ads.
I don't necessarily think the solution is ads, but they're like an easy solution, right?
You can easily throw them up.
And as long as you control the site, like read the docs, for example, it's not hugely in the way for anybody.
Michael, can I jump in with one comment on this?
Yeah, please do.
Go ahead.
Sort of bridging what both Eva said and Donald said.
I think one thing that we could do is perhaps leverage better instead of ads, but use the site to really honor and thank the sponsors.
And to give the sponsors some greater visibility on the sites for actually taking the time and belief and effort to sponsor us.
Yeah, that's a really good point.
You know, maybe this is a good time we could sort of switch to trying to brainstorm about what can we do.
I mean, we've sort of been circling around that a little bit and what people have tried.
Maybe what could or should we try?
I think having the sponsors highlighted really clearly could easily make it more appealing to sponsor these projects, right?
Like if it was a small icon logo at the bottom of like the homepage, that's one thing.
It's another if Rackspace gets to somehow be featured or Red Hat gets to somehow be featured in like a thing that is relevant to them, right?
Maybe, for example, on the stuff to do with cloud computing.
Red Hat gets a little, you know, like the packages to do with cloud computing.
Maybe Red Hat gets some sort of visibility for, say, OpenStack and similarly for Rackspace.
You know, something like that.
Eric, what do you think?
So we actually have been thinking a lot about this.
I mean, we don't do things quickly and without thought.
And so one of the big things is we formed as a business and not a nonprofit because basically we do this as trying to prove a model.
And so we don't want to constrain ourselves.
And so when we looked at doing a nonprofit and what they're allowed to do in terms of, you know, quote unquote sponsorship, you're basically allowed to do advertising.
But there can't be a call to action is at least the way that I understand it.
So you see this, you know, similar.
Django is doing this where they actually have a more visible thank you to their donors in the documentation.
But it's very much a, you know, thank you, Red Hat for sponsoring or, you know, thank you, you know, whoever.
They can't say, you know, come buy our new product for $10 off this month.
And so that is the fundamental difference.
Right.
And so we thought as we try and kind of prove this model and really think through it, we didn't want those constraints.
But some of the people we're talking to very much do just want that kind of more sponsorship model.
And so really our goal in the long term is to build an ad business to the point where we're able to transition that with our existing sponsors to a more nonprofit sponsorship model.
But really to start, we saw, you know, the Django Software Foundation did this and they are they have not hit their goal for the year.
Just in a traditional kind of nonprofit donation model, even with a more visible thank you.
Whereas Django REST framework actually has been successful with this model.
And so, you know, there's there's a little bit of different conflicting views.
But I think definitely kind of, you know, making the sponsors feel like they're getting something for their money is really the value.
And so we went kind of purely for trying to build a model where we could actually give sponsors the most value possible.
And then if we're successful in that and I can, you know, pay my rent each month, then we can start to impose more kind of strict regulations on what we're able to do.
But by starting kind of as a nonprofit or as a for profit and allowing ourselves to kind of transition into a more kind of nonprofit style model, it gives us more flexibility to get it off the ground.
That's an interesting point that you need the room to experiment.
I think this is a pretty new space of trying to take a thing that was basically for free and turn it into a business, especially a thing that is free and people donated freely to it and turn it into a business.
That's a real interesting challenge, right?
And so I did.
Actually, if I can add to that a little bit.
Sorry to interrupt.
Yeah, go ahead.
So at the PSF, we actually do have maybe a different form of what we're discussing called success stories where we so this was developed in the redesign for the website, but it's not used as much as I would like it to be.
So pretty much what we do is we say to our sponsors, especially top level sponsors, say, hey, why don't you write us a success story that we can post on our website of how Python has helped your organization grow or to where it is today?
And I think that if we could maybe use that as a way to expose our sponsors more, I think it would not only please our sponsors, but it would please the community because it just wouldn't be like, hey, buy this product.
Right.
Okay.
That's interesting.
Yeah.
People basically get to highlight how they're using Python in whatever area they're interested in, like whatever in their cloud computing platform, if they're a cloud provider or something like that, right?
Exactly.
Yeah.
Eric, you were going to say something as well.
Oh, yeah, I was just going to speak to Donald's point because I think it is super important that we did actually spin up a paid hosted model.
And that is actually a separate entity.
It's at readthedocs.com and it is a completely separate thing.
And so that's kind of how we were hoping to address that balance between, you know, you're not paying to donate to a business.
The advertising on readthedocs.org supports the readthedocs.org hosting and kind of costs, not hosting because Rackspace pays, but, you know, the cost of maintenance of that platform.
And so you're not donating to a business, right?
You're just allowing.
It's one method that we're generating income to become sustainable.
Not, you know, I'm not like lining my pockets, you know, with ad money or whatever.
Right.
And so that is something we thought a lot about.
And we have provisions.
We have different, you know, entities and all that kind of stuff.
That's something we are really, I think, is super important, right?
You can't just be like, hey, we're going to start making money now and expect people to kind of, you know, donate to a business.
It does have to be done kind of thoughtfully.
Donald, your point was really interesting.
And I think it touches on one angle of what I think is a very careful balance.
Like, what if PyPI, let's say, went to some kind of business model that was, well, it looked like a business, like you said.
And the business was doing okay.
It was making $10,000 a month.
And then the people who donated to it said, you have a business.
Why would we donate to you?
We were pulling our $40,000 a month funding.
You know, all of a sudden, you know, you've killed the golden goose by trying to keep it alive, right?
Yeah.
And to their credit, I have not actually talked to them about this.
It has been one of my concerns when I've talked to people about ideas about how we can, you know, sort of bring in some more money into PyPI in order to enable us to, you know, maybe hire more people to develop it or pay for some services where we weren't able to get donations, you know, things like that.
And, you know, that's been sort of one of the big concerns there is how are these donors going to look at that.
And, you know, we do try to, when we develop it, not depend too much on one specific donor.
So we do try to spread out over multiple.
We do try to develop things so that we're not developing just some sort of proprietary API.
If we do, it's shimmed in in a way that we could, you know, swap in some other component.
So, you know, what do you think about this?
Like, just listening to you guys talk, one of the ideas that was running through my mind is, Eric, I like your idea of having a private read the docs.
One of the ideas on PyPI that was coming to mind is, well, what if you could have like a premium listing?
So, like, I use Stripe and I pip install Stripe.
And that comes down from there.
But that's, you know, Stripe is a very successful business.
I'm just grabbing an example of something I use that's for pay, basically, right?
What if Stripe could have like a premium listing on PyPI and all of the bandwidth and all the hosting charges for the premium listings were not passed through to like Rackspace and Fastly and stuff?
That could be doable.
We'd have to essentially stand up almost a second PyPI to handle that just because there's no real way to discriminate between, you know, different packages where they go through.
I mean, the package files themselves could easily be hosted through another mechanism.
But the repository API, the web UI, all that stuff would still have to actually go through, you know, Fastly and then Rackspace and the various companies.
So it would be hard to completely separate them without making them two entirely separate entities.
Okay.
Carol, what are your thoughts on ways that we might be able to mix things up a bit here?
Looking in from the outside, Eric and Donald are, you know, living this day to day, right?
Yeah, I mean, I think it's one of those things.
I think it's sort of a slippery slope, because if you did do the like sort of like extra like per company or whatever, PyPI, you kind of open the door for losing the huge benefit of PyPI, which is everybody sort of goes to the same place.
We've seen it in science and data science.
There's some great stuff that came out of Conda and now more so Conda Forge along with PyPI.
But it also kind of increased the burden of, okay, how do we install things?
Do we use PIP?
Do we use Conda?
Yeah.
I'm not sure that additional complexity is something that really benefits our users.
Whereas, hey, this is where we go.
Yeah.
Easy decision.
One of the things I wonder is if we couldn't use like PIP.
Donald's done such a great job of improving it with little readouts as your thing progresses.
And even something as basic as, did you know, pip installs X number of terabytes of whatever data in a month or whatever, or whether that's on the PyPI site.
But just building awareness, because I think it's going to be a combination of donations that you're going to get.
You're going to get some individual donors that give to things like Read the Docs or PyPI or infrastructure because they see the value in it and they use it in their jobs every day.
And it might not be what I develop every day, but I use it so much and I would hate to have it go away.
So, you know, personally donating to the packaging and to Read the Docs for me was a no brainer.
But I'm in a position where I can do that.
Not everybody can.
So, you know, we don't want to set up like a tiered structure to make people feel bad for giving what they can.
Yeah.
And where they can.
But I could see, well, a couple of things.
One is Eva and the board and the greater PSF team has really worked hard the last year and a half to really level up the governance of PSF and to really look critically at what nonprofits are doing and how we can increase sustainability.
And I think some of the first steps that got put in place was to make some strategic hires to support Eva and the sustainability in different areas of the foundation.
And now it's really a matter of, okay, the next phase is really, okay, let's take a critical look at all of these things and come up with some best practices and plans.
Just like we do in development.
Like, you know, we run things through continuous testing or integration and, you know, to work smarter, not harder.
Yeah, exactly.
Like leveraging, like you said, continuous deployment maybe to make sure that if something goes down, it's like a push button to create a new instance of it rather than a scramble for four days.
Something like this, right?
Right.
So my feeling is I would much prefer to see the big corporate companies that are really benefiting from Python somehow have a way to fund it but feel like they're getting something a lot out of it, right?
Like that's kind of why I brought up the premium PyPI package where maybe like if you are a company and the PyPI package is about a thing that is really important to you, maybe somehow that listing could look different and they could pay for it but be really happy to do so, you know, or something similarly on read the docs.
I'm not really sure but I feel like the donations are great and I've given some money to PyPI but I don't feel like any amount of money that I can personally give is going to come anywhere near me.
Near what?
Microsoft, Red Hat, these other companies that have tons of money, Google, if they're making such big use of it and actually have a product on the other end.
I don't know.
Eva, what do you think?
So I sometimes find myself persuading people that open source needs money and that not everything can be handled by the community and volunteers.
I even remember when I was hired, it was a taboo for me to get paid to work for the PSF.
Because everyone was of the mindset that everything should be done by the community.
But I definitely agree that corporate sponsorship is where it's at.
And I feel that more corporations need to become aware of the fact that maintaining a software language has multiple angles.
A lot of those angles require funding.
Corporations that use Python should financially support Python in my opinion.
And these companies are sometimes making millions and millions or billions of dollars on this stuff.
And if they cave 0.0001% of that revenue to the thing that their business is based on, it would transform it and be like nothing in their space, right?
Exactly.
And since Python is a core of what they do, I strongly believe that having good infrastructure behind the language is vital for the sustainability of that language.
I mean, especially nowadays, there are so many options for programming languages.
And we just have to increase the number of reasons we give our developers to stay in order to make Python sustainable for the long run.
I mean, a little bit goes a long way.
I totally agree with you, Eva.
Eric, what do you think?
100% behind a corporation's paying.
I mean, I think depending on Carol giving money to read the docs each month is very much similar to requiring her to pay us, right?
Like, we would never require open source people to pay us.
And asking that the people working on open source pay money to support the infrastructure while companies free ride, it just feels morally wrong to me.
You know, Carol is contributing enough.
She doesn't need to give us money.
And people that are individuals do not need to give us money.
And I've actually toyed with removing the ability to give individual donations from read the docs because I think it's a false flag.
Like, it's never going to solve the problem.
And the only people that are going to donate are already giving their time.
And asking them to give money as well is just, it makes me sad.
It does help, but it's like a small band-aid.
It doesn't really solve the sustainability problem, right?
I think it distracts, right?
Yeah.
Like, people are like, oh, you just need to get more donations from individuals.
And it's like, that's not the solution.
Please stop suggesting that as the solution.
And I'd be remiss not to mention a couple things here.
So Nadia Eggbolt, I believe is her last name, did an amazing job for the Ford Foundation doing a report on this that's like 100 pages.
And she talked a bunch about Python stuff.
She talked to myself, Keith McGee, a bunch of other people.
I think Donald as well, for sure.
About these problems.
And I think that is a very concrete report.
And it really does talk about a lot of the different solutions that have been tried.
I think especially with PyPI and kind of the pip example you cited, doing a kind of Wikipedia-style awareness campaign, right?
So if you put in the pip install logs for a week, like, hey, donate to PIP.
This stuff is not free.
We're run by a nonprofit.
You know, very similar to how you see at the top of Wikipedia, right?
Like, they really have to, like, push and be heard.
And I think there's still a huge number of people that can kind of claim ignorance of this issue.
And I think if you start putting that on every PyPI page or PyPI page, every read the docs page, every pip install, that would actually start to move the needle in terms of awareness and community, kind of galvanizing a community.
And so I think something similar to what Ruby is doing with the Ruby Together efforts, where they're actually kind of they've taken their kind of core infrastructure.
They've built some branding around improving it and then kind of showing results either kind of think monthly with those kind of people has been a really interesting thing.
They're still nowhere near where they should be in terms of funding.
But I think if we kind of took, you know, PyPI, read the docs, even just those two, really, and, you know, in PIP, even, for example, and we're like, hey, let's run a one week or a one month campaign, you know, maybe around PyCon, for example, or like, you know, the week up and after PyCon or something where it's like, hey, like, your infrastructure, you know, tie it with a keynote at PyCon U.S.
Tie it with, you know, these massive things where everyone during the sprints is going to see this.
Everyone at their work is going to see this.
You know, I think I think we've been very coy about this because it's something that we're kind of we feel awkward about money and open source has been this taboo subject for a long time.
But I really do think that we're now at the point where we really have to kind of build sustainable solutions that bring the community in.
And so I think that's kind of my my big picture idea is really that kind of I view read the docs at its core like a library, similar to the government stuff we were talking about earlier.
Right.
We should be funded by taxpayers, you know, and if we're not able to, you know, one of the other things I thought about is going to VCs and doing, you know, a 1% for open source or something along those lines.
You know, I think the things that the green movement and kind of the environmental people are dealing with are very similar.
Right.
Where there are these externalities that people don't feel.
It's a really interesting angle to think of it as this is an externality.
Right.
This is an expense that people that use open source don't have to pay because it's somehow covered.
And basically, a lot of it is pushed on to the companies that donate like Rackspace and Fastly.
Right.
They're covering the cost of all this.
So all the other companies in the world can go make money and not worry about it.
Right.
Like open source contributors burning out is the global warming of the technology industry.
Right.
Because I think there's something really special about the volunteer effort and how people are putting forward all this effort for nothing but to bring some project to fruition.
But at the same time, when you see billions of dollars being made by for profit companies on top of this infrastructure and on top of this, these projects, it seems like there's got to be a way that they're not crushing the people trying to do the work, you know, with their weight.
This portion of Talk Python to me is brought to you by GoCD from ThoughtWorks.
GoCD is the on-premise, open source, continuous delivery server.
With GoCD's comprehensive pipeline model, you can model complex workflows for multiple teams with ease.
And GoCD's value stream map lets you track changes from commit to deployment at a glance.
GoCD's real power is in the visibility it provides over your end-to-end workflow.
You get complete control of and visibility into your deployments across multiple teams.
Say goodbye to release day panic and hello to consistent, predictable deliveries.
Commercial support and enterprise add-ons, including disaster recovery, are available.
To learn more about GoCD, visit talkpython.fm/gocd for a free download.
That's talkpython.fm/gocd.
Check them out.
It helps support the show.
Donald?
Well, yeah, and, you know, it's interesting in a way because I don't want to name names or anything,
but if you go through many, most, you know, sort of web services companies that have some sort of API client that, you know, is available on Python,
you'll see, you know, typically you'll see, you'll see, you'll see, you'll see, pip install, you know, my whole library for that company.
So, you know, those companies do tend to drive a lot of traffic towards PyPI, which, you know, increases our costs.
And they sort of get that for free.
Now, we're happy to provide that for free, but, you know, they do impact our bottom line to a large degree.
I really think that the best sort of end case is for these companies to give back.
You know, I worry about, like, the Wikipedia style, the donation drive and such, in that we're going to end up just getting money from developers.
Again, someone who goes to PyPI online is likely going to be a developer looking for a library.
Someone who takes pip install on their command line is likely to be a developer.
You know, and the hope there, I guess, is that they will funnel that up towards their management chains.
Say, hey, we depend on this thing.
Can we give it money?
But I worry that the most likely case is that they will maybe give some money themselves and it just kind of ends there.
I'm not necessarily sort of super skilled at the donation side of things.
You know, I reach out to companies and beg them for services.
But, you know, I feel like identifying which companies are big Python users and then reaching out to them and asking them for donations is probably going to be our best bet.
And in many ways, PyPI is lucky because we do have the, you know, we're owned by the PSF.
So there's already, you know, a infrastructure set up to get donations.
And, you know, we're likely, as far as PyPI is concerned, best of trying to improve upon that.
I think that there is actually a path forward where everybody wins, where Python open source infrastructure is funded and supported better.
It's not all the eggs in one basket, even though thank you, thank you, Rackspace and Fastly and so on.
And these companies, like you said, the biggest ones that drive the most traffic, they feel like somehow some change has been made.
So they actually get better visibility.
They get better.
Their thing that they have a Python library for is doing better with Python developers because of it.
I don't know.
I just, the ad model may work somehow.
The donation model, while really appreciated, I know, is it's not really enough to sustain, like, a person working all the time or, like, you know, the cost of a lot of times.
It feels more like there's the yearly drive.
So, you know, we're kind of getting near the end of our time, but do we have a solution?
I'm not sure we found any solutions, but I feel like we've started an interesting discussion.
Eva, what's the PFS story here?
Like, what do you think?
For the PSF, I definitely have short-term goals, which I guess is the best solution I can come up with at this time.
I mean, we've been talking about trying to maybe get traffic statistics that are more targeted.
Say, hey, this is how your team's using this infrastructure.
And I'm not quite sure if anything beyond them benefiting from it should be a part of the reward for sponsorship because they're already getting a lot from just using it for free.
So maybe that's just it, just showing them this is how exactly your team is benefiting from Python and the infrastructure.
It would be great if you can give back.
I mean, it's not like every sponsor has to give us $30,000, $50,000 a year.
If all corporate sponsors that use Python give a little every year, I think that could add up to hiring two developers.
I mean, within the PSF, I want to have an environment where my staff, my team is not worried about how long is my job here for because it's pending on some kind of funding.
I want to make sure that I can pay someone at least five years before I hire them.
So just taking steps like that.
Okay.
Yeah.
I think on one hand, you know, it is a big problem.
But on the other, like you said, Eva, it's just if people, people, by people, I mean companies.
If companies gave a little, it would solve it straight away, right?
I still feel like having some kind of business model that is doesn't seem incongruent with open source and the whole story, but does does bring in a little bit of stability would be a good thing.
Carol, what do you think coming from like a Jupyter scientific person perspective?
I've got two major thoughts.
One is I would highly encourage folks in the Jupyter data science world.
If you're looking for a great project to do analytics on, approach us because there may be a project that you can look at to analyze the traffic data and, you know, see who's using it, who's consuming it.
And really help us out with the analytics side of things and the reporting side of things.
And then the other thing I think is I had the pleasure of attending an open source sustainability thing with Nadia Agbel earlier this year that O'Reilly put on.
And she and I come from both business background as well as nonprofit.
And I think Eric kind of hit on one group of donors that benefit a lot from open source yet don't directly donate a whole lot to it.
And that is the venture capitalists.
And if you took the top 20 venture capitalists and they donated 10, 25,000 to sustain the community, it would go a long way.
And I think that may be another area that we look a little closer at and say, okay, you're funding hackathons and giving money away to potentially promising companies down the road that may or may not make it out of their first year of life.
But we know that the Python Foundation has been around for a long time.
We know that Python's been around for a long time and perhaps go back to them and say, hey, you need to support the infrastructure that you are directly benefiting from.
Yeah, that's an interesting point.
And VCs were on my mind as well.
And these high growth companies.
One of the things that came to mind when you were saying this, what if there was some kind of PSF funded or officially funded expert, a group of experts that could come in?
So instead of just going to the VCs saying, look, you have these startups and these accelerators.
And because you benefit from this, you should donate to us.
But because you benefit from us, if you donate to us, we'll actually help your companies get started by giving you 10 hours a week of expert advice.
And obviously, that would have to more than cover that expert's time and energy and so on.
But maybe there's some kind of partnership.
Who knows?
Donald, final thought.
Where do we go from here?
I think right now, PyPI is a relatively okay place as far as our hosting infrastructure goes.
Our donors have been fairly stable and we've done a pretty good job at diversifying them.
It is always scary that one of them could drop out and how we would handle that.
Looking forward, I do think that the best way to look at this is how to get your corporations, VCs, etc., to sort of contribute back.
And that's kind of where I'm at.
Okay.
Good to hear PyPI is not just about to vanish or anything.
But still, it needs a much more stable base, I think, given its vast importance.
Eric, final thoughts?
I think the last thing I said were probably my final thoughts.
All right.
Great.
I mean, I think, yeah, I'm obviously very much, you know, I think I have personal stake in this.
And, you know, I think everyone else here is paid, you know, or until recently has been paid full time in some fashion to work on this.
Whereas I have been watching my bank account dwindle trying to solve this problem.
And so I think that's why it's a little bit more personal for me.
Yeah, absolutely.
And why I have a little bit of, you know, passion, maybe.
Well, you had some really interesting points.
And, you know, I can definitely share some thoughts with you.
Like, in February, I went full time on having just my podcast be my 100% income and the training courses that I built on top of it.
And it's not open source exactly, but it's, you know, it's working in the open source community to, you know, pay my kids' school bills and mortgage and stuff.
And it's stressful.
And I don't have exactly the same constraints because I kind of live alongside open source, right?
Like, I can do ads.
And people, I think, understand for the most part, like, this is paying my bills.
So it's okay.
We'll listen to a 30-second ad.
But it's a challenge, right?
Yeah, definitely.
And I think the biggest thing for me is that, you know, four years ago, this felt like nobody was talking about this.
And I really do think that the awareness has just slowly been raised.
Because the work that Nadia did was monumental and just kind of the fact we're doing a podcast about it.
And I really think it is more, you know, it's one of those things where we just really do need to keep building awareness.
Because everyone I talked to was like, oh, read the docs.
I thought that was like a VC-backed company.
Or, you know, it's like we thought.
That's an Eric-backed company.
Exactly, right?
But I think I haven't personally done a great job of raising that awareness and been very skittish about introducing money into this ecosystem.
But I mean, I think at the end of the day, especially for infrastructure, right?
Like, people will happily work on cool new features, like, for fun.
But, like, paying someone to wear a pager is something you have to do.
Like, nobody wants to sign up.
And I would feel bad making somebody sign up for free to wear a pager and get woken up at three in the morning to provide a service for free to corporations.
You know, like, that's just not something that I feel good about in any aspect of it.
And so I think there is a fundamental need of money for a subset of these efforts.
And I think the community is coming around to that.
I think the conversations are happening.
And I think we're really in a very positive forward path.
And we just need to keep doing it.
All right.
Well, I hope that we can somehow bring this up in PyCon this year in June.
And maybe some lightning talks, maybe a keynote, hint, hint, hint, nudge, nudge, or some open spaces or something.
But I think it's great these conversations are happening.
And thank you all for being here.
It was really interesting to brainstorm about what we can do, what the problems are, and what the solutions might be.
Thanks, everyone.
Thank you.
Yeah, thank you.
Thank you so much, Michael.
Yep, thank you.
Yep, bye, guys.
This has been another episode of Talk Python to Me.
Today's guests have been Donald Stuffed, Eric Kulscher, Carol Willing, and Eva Jowalska.
And this episode has been sponsored by Rollbar and GoCD.
Thank you both for supporting the show.
Rollbar takes the pain out of errors.
They give you the context and insight you need to quickly locate and fix errors that might have gone unnoticed until your users complain, of course.
As Talk Python to Me listeners, track a ridiculous number of errors for free at rollbar.com slash Talk Python to Me.
GoCD is the on-premise, open-source, continuous delivery server.
Want to improve your deployment workflow but keep your code and builds in-house?
Check out GoCD at talkpython.fm/GoCD and take control over your process.
Are you or a colleague trying to learn Python?
Have you tried books and videos that just left you bored by covering topics point by point?
Well, check out my online course, Python Jumpstart, by building 10 apps at talkpython.fm/course to experience a more engaging way to learn Python.
And if you're looking for something a little more advanced, try my WritePythonic code course at talkpython.fm/Pythonic.
You can find links from this episode at talkpython.fm/episodes slash show slash 84.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, Google Play feed at /play, and direct RSS feed at /rss on talkpython.fm.
Our theme music is Developers, Developers, Developers by Corey Smith, who goes by Smix.
Corey just recently started selling his tracks on iTunes, so I recommend you check it out at talkpython.fm/music.
You can browse his tracks he has for sale on iTunes and listen to the full-length version of the theme song.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Smix, let's get out of here.