PyCon: Everybody Pays

by jesse in , , , ,


There's been some recent discussion about DjangoCon(.eu | .us) and whether or not speakers should have to pay for admission as well - see Chris Wanstrath's (of Github) tweets (here and here) and this Convore thread for examples. Obviously, as PyCon is the "big dog" so to speak for Python conferences, everyone looks to "us" for a model to work from, or how we manage things. I've seen a lot of poop slung towards the DjangoCon organizers, mainly due to a lack of knowing "why" certain policies (such as "Everyone Pays") exist for DjangoCon, PyCon, and other conferences.

As co-chair and program committee chair last year, and program committee chair the year before, and now chair for the next two years - I figured it might be good to take a moment to explain the rationale behind PyCon's approach - as well as some statistics about the budget. I'm not going to state that this policy is perfect; nor that it won't be changed; I also will not release the budget publicly - I don't think giving everyone a spreadsheet without the context of the hundreds of man hours of work that go into it is useful, at all.

Important Note: PyCon is organized and managed by the Python Software Foundation - this means that, as part of being a 501c3 charity, some of the financials from past PyCon is available as part of publicly accessible financial documents of the foundation. You can find those on the PSF's site.

The same reasoning may not apply to a conference that is organized by a commercial entity or is done for profit. OSCON is a commercial conference, so having speakers get in free is generally expected. is in the middle - it is organized for profit by a commercial entity, but it also contributes heavily back to the Django Software Foundation. is managed differently as well.

Policy and Financial Aid

First, what is the "policy" - well, first, it's not a policy per-se; it's part policy, and part tradition. The policy is "Everyone pays for a ticket" - attendees, tutorial presenters, organizers (meaning: all volunteers, including the chair) and sponsors - everyone pays their way. Yes, this means Van and myself both paid for our own tickets to attend. Everyone is treated as equal - sponsors get free admissions as part of conference sponsorship packages, and keynote speakers may be provided with either compensation or admission depending on the negotiated deal (some keynote speakers cost money, for example).

Now; an interesting aspect of this is that PyCon, as a conference, offers a very generous financial aid program - this means that some attendees, speakers, tutorial presenters, etc have some, or in rare cases, all of their expenses such as flight, hotel and admission provided to them from the PyCon budget. PyCon goes out of it's way to encourage people to apply for financial aid - even if we can't cover all of your expenses, we will give you free admission based on need. The FA application process is simple, and straightforward. It's also very liberal - the only caveat is that speakers at the conference "get bumped to the top" of the applications so that we don't lose a good talk because of financial need. We also don't ban anyone from applying (for example, I needed assistance in 2010 even as the PC chair).

We use the FA budget to not only help the "normal" attendees of the conference, we also keep an eye towards diversity - for example in 2010 we had a specific grant program (funded by Google) for women to attend PyCon - which they did in amazing numbers! We also try to help more people with less money than less people with more money - we want to spread assistance out as much as possible. This is why FA requires room-sharing at the conference hotel, this is why we may only cover part of a given applicant's costs - we want to help more people.

As you can guess - since financial aid is a part of the budget, we allocate a set amount of money to this - but, without a solid budget (meaning, admission ticket sales, sponsorships, etc) we can't have it - it's actually a dice roll. We can guess at how much FA we can carve out of the budget at the start of the process, and we will award that amount - but that means if we have low attendance, don't book enough rooms, or our catering costs spike, or lack sponsors, the conference can lose not insignificant amounts of money helping people. The rub being, you don't know for sure if this will happen until the conference actually happens.

So, how does "everybody pays" play into this? In two ways. First, it helps hedge our risk, institutionally speaking. PyCon had a good/bad year in 2009 - good for the attendees, but horrendously bad financially. We made various commitments in 2008 just as the markets were peaking, and we lost a lot of money when everything went south. Since then, it has been our budget policy to make sure that our revenues will cover our hard costs even if there is a 15% dip in attendance and a 35% dip in sponsorship.

Second, you may have guessed that the "everybody pays" policy allows us to pad the financial aid budget. This has the direct benefit of bringing more people to the conference, increasing the diversity of people attending, getting a larger proportion of the community together, etc.

I'm happy to say, that on most years, we very happily break our financial aid budget - meaning, if we have a positive outlook, we will gladly overspend on financial aid and take less "profit " for the conference. The point of the conference is the community, it's not about the conference! We help the community as much as we can by helping to cover the costs of people who would not otherwise be able to attend.

History and Tradition

Once you start organizing a conference you start to rapidly realize how costly things can get - and if you don't have sponsors with giant bags of money, or the conference is not being run for profit (such as OSCON), you can quickly get into trouble if you don't have a policy in place that will ensure financial viability. PyCon came from very small, humble beginnings but has grown year over year consistently - maintaining the "everyone helps, and everyone pays" tradition originally set forth.

It is my understanding that the policy/tradition has as much to do with financials as it does with "the feel". No one is treated specially, we - meaning the community - put together the conference, we are taking the financial risk that comes with it. We are in it together, and that means "everyone helps, and everyone pays" - it is the most equitable solution that helps us maintain fairness and the flavor/feel of the conference. When you realize that even Guido has to buy a ticket (even if it was paid for by Google) or that Van Lindberg had to buy one - it suddenly makes you realize that all of us truly believe in the spirit of "we are all in this".

Speakers; as a an additional guideline, while always paying for a ticket; always pay at the discounted early bird rate no matter when they register. So yes, we do discount them, but no more than anyone else who registers within the early bird window.

As an aside, the "everybody helps" is also part of what makes PyCon special. When people come to other conferences, they frequently come expecting to be coddled and catered to. When people come to PyCon, we hope they come expecting to contribute. Having everybody contributing is at the core of the best parts of PyCon - from stuffing bags, to lightning talks, to the wonderful Testing in Python BOF.

Hard Costs, Stats and Risk

So what makes up a PyCon budget? Well - Van covered some of it in his wonderful "Behind the Scenes" post for PyCon 2011 - but in more detailed terms of percentages of the total costs for the budget:

  • Catering (Food, beverages): 54%
  • Networking: 5%
  • Audio/Visual and Video Recording: 13%
  • Payments to Tutorial Instructors: 6%
  • Misc/PR/Sponsors and Administration: 16%
  • Swag: 2%
  • Financial Aid: 4%

Catering, plus Financial Aid and video recording is 70% of the budget alone. The total value "spent" for financial aid alone well exceeds 50,000$ We spend a massive amount of money for audio/visual and the video recording making all of the talks available on the web (see the python miro community). Tens of thousands of dollars spent on networking.

We could forgo feeding people - but with a conference that runs from 8am to 6pm for 5 days, that would suck - and people needing to leave to get food would be disruptive and ruin the flow. We could forgo recording the videos. We could do a lot of things to cut back and lower the budget numbers so we could give more away (such as comp'ing speaker tickets), but that doesn't make the risk and costs from the hotel go away.

  • Average Revenue per attendee: ~$300
  • Average Cost per attendee: ~$465

In total - these costs (for 2011) came to well over 600,000$ - that's right. Over half a million dollars in hard costs for a conference of 1,380 Pythonistas. Much of the payments, guarantees, deposits, etc have to be put down up front of the actual conference with no guarantee that we will make our sponsorship or attendee numbers. That means, in the case of PyCon - the Python Software Foundation fronts potentially hundreds of thousands of dollars in payments and risk. We also expect these to climb with the move of the conference to Santa Clara.

Conferences are unknowns - you put up a lot of time, energy and money - lots of money - and you hope you hit certain numbers. For example, you make a contract with the hotel that says "we will have X number of people book X number of rooms nights" - if you don't meet those numbers? The hotel penalizes you a stunning amount of money. You make a contact for catering - saying that you will serve X number of meals - and if you don't hit that? You get penalized. You put a lot of faith in making numbers on:

  • Sponsors - without corporate sponsors, we simply could not exist (at this scale), period.
  • Attendee Numbers - You expect X number of attendees, broken up into "corporate, individual and Y" rates - corporate rate tickets are where you make the bulk of registration rates.
  • Hotel Rooms - if you don't hit your contracted numbers, you will take a bath

Do you know what happens if, for some reason - say an economic downturn - you don't make those numbers? Your conference loses over $230,000, possibly more. That 230k number? Right around the amount PyCon 2009 lost, representing a massive financial loss for the Python Software Foundation. Yes, you try to mitigate the risks by careful planning - if you're lucky, you get some insurance to cover some of the potential losses. PyCon is actually really lucky in all of this - we've grown enough that we get to leverage economies of scale with the contracts we deal with. Small conferences? Not so much - they get harder in the face of failure, and they don't have the bargaining power we have..

It's a delicate balancing act, requiring careful planning and a lot of work to drive attendance and sponsorship - negotiations with Hotels, Catering, Unions, are all things that have to go right in order to make a conference that even stands a chance of not losing you massive amounts of money. In the case of PyCon - a massive loss of money (such as 2009) could cause the foundation to go bankrupt and dissolve. As it is, the foundation, already spartan in spending cut back even further to protect itself which represents a net negative for the Python Community.

Where does the profit go?

Alright - I've outlined the philosophy, the scale and the risk. Now, you're probably asking where, if we have it, does any profit from the conference go? Easy - straight back into the community.

Whatever profit - really, money left over, goes to cover the initial costs/risks for PyCon the next year, and the years after - it also goes to the Python Software Foundation that in turn, reinvests that money into the community (see the foundation blog).

Having a healthy positive margin also means we can increase things such as the financial aid budget for the next year, allowing even more Python developers to attend.

Why not run a budget that aims for 0$ +/-?!

Because, that is simply insane - you can aim for minimal profit by reinvesting into things such as financial aid, or other perks for the attendees but only after you have guaranteed you're going to make your numbers - see the issue? At best, you budget is a highly refined series of educated guesses. At worst? Someone goes bankrupt - at smaller conferences such as, where some costs and contracts are secured by an individual and their credit card?

That person goes broke, because the entities you signed contracts with will get their money.

So, you never, ever aim for a loss, but you also don't aim for extracting "maximum value" from conference attendees. You aim, you plan, and you hope to provide the best value and experience to attendees and sponsors - you do this through a lot of hard work and sweat. You make sure attendees walk away raving about the conference, you make sure you generate the maximum return on investment for the community.

In Closing

Historically, PyCon has never been aimed at "extracting money" from the community - it could be run a lot more profitably. We could increase ticket rates, reduce FA and walk around in Nascar-esque suits with sponsor logos on them - there's lots of things that could be done to make PyCon a massive profit center for the PSF. We don't though - why? Because, that defeats the purpose of a community conference, put together by and for the community.

We take what money we end up with and we sponsor the sprints at PyCon itself, we hold the language and virtual machine summits. The PSF reinvests it into the Python community as a whole (see the sprints project, for example, or the 10,000$ check we gave to PyPy). The money is given out in the forms of developer grants, holding sprints, providing sponsorship to smaller Python conferences all over the world, outreach and education initiatives, etc. No one gets a shiny new car or anything - money that comes from the community conference goes back into the community. You can see how much goes where if you peruse the PSF resolutions page.

PyCon is beginning to also outstrip the ability for a small group of volunteers to put together - more and more we've had to bring on commercial entities (whom we have to pay) to assist in organizing or doing specific things (such as registration, or website development). I fully expect PyCon 2012/2013 to quickly hit the attendance cap meaning we're going to have more scaling issues and higher costs - this is a fundamentally good thing - PyCon, it is felt, can sustain it's current feel and quality up to a maximum of 1500-2000 attendees.

We do not have the intention of raising that cap.

Instead, we - as the foundation - intend on encouraging smaller more regional conferences such as PyOhio to grow - PyCon will continue to be the "big dog" so to speak - but it being the big dog will allow us to further cultivate and pollenate the entire Python community and ecosystem.

Given all of that - as the PyCon chair for the next two years - and being relatively comfortable that we will again, put on a highly successful conference - I am exploring the idea of steeply discounting the cost of tickets for speakers. I feel that not only is the conference viable once again, but that the speakers do help make the conference what it is - last year we had over 200 talk and tutorial submissions. All of those speakers submitted talks knowing that they would have to pay for a ticket to attend - but given the positive outlook, I'm comfortable in thinking that we will be able to provide accepted speakers with a discount to thank them for their talk.

It's all about community, and reinvesting in it in the right places, at the right times, and managing your risk. The risks putting on a conference - even a small one (especially a small one) are massive, but the returns - especially when you're standing on a stage in front of 1380 fellow Python hackers handing a big cardboard check to a fantastic project?

Well, the returns are well worth it.


PyCon Wrapup or "stop fidgeting"

by jesse in , ,

3405504555_e4422b42f6.jpgAh, PyCon 2009 has come and gone. I'm a little late in doing a wrap up - but that's primarily due to the fact I wanted to spend time with the family, and not on the computer since I got back mid-day Thursday of last week. That - and other things in my life are a little worse-for-wear, so my brain's been full of "other stuff" rather than basking in the glow of: The best pycon, ever

Yeah, I came out and said it. For me, it was my 4th(?) PyCon, and not to disparage the past, but this one was the best planned, best executed and most fun for me. Sure, it had a few negatives (Chicago being one of them), but by far the pluses outweighed any minuses.

Here's a summary of things I can remember.

The summits

I got in mid-day wednesday and broke into the VM summit. I was immediately slapped with the unladen-swallow announcement, which made me do a little dance and immediately start pulling down the code. For the most part, since I was past the introduction piece, I sat in back and had interesting discussions with Thomas Wouters, Brett Cannon and others.

Later that night, I sat down and spent some time with unladen swallow - mainly getting LLVM all happy and pulling down the trunk (when I should have been using the released tag). I also spent a fair amount of time massaging my slides for both of my talks. Nothing quite like last minute changes.

The next day was the language summit. Here a bunch of people much smarter than me sat down and discussed the future of the language. I can't even begin to describe everything that happened - some basic highlights are:

  • Some discussions around making python 2.7 be the last release of the 2.x line. I think the general consensus was to continue to use 2.x as a ramp into 3.0, but in general if migration to (and from) 3.0 was faster/easier, then the adoption barrier for 3.x would be greatly lessened. Most of us finally agreed that the 2.x line should end with 2.7.
  • On 3.0 - porting issues and pains were discussed, things like 2to3 being slow, lack of incentive (3k being "a better language" notwithstanding) being one of the big issues. Someone (Guido I think) floated the idea that big features only go into the 3.x branch, ergo providing greater upgrade incentive. I don't think a lot of people disagreed with this and in fact, I took it to heart during the sprints when looking at feature requests for multiprocessing.
  • Which brings us to 3to2 - several developers expressed that if we had a tool which could translate python3 code to python2, then they could start writing their frameworks/tools in pure python3 and then back port it. I don't recall anyone disliking this idea - but no one wanted to get the ball rolling. So I raised my hand. In essence, I volunteered to get the ball rolling, which I have done. Benjamin Peterson will be heading it up primarily - but anyone is free to contribute (and some already have). It's got potential as a google summer of code project.
  • After that we discussed what CPython can do to make integration/testing easier for alternative implementations. We agreed that being able to mark tests as "cpython only" and breaking things in the repository up in such a way to make integration of the standard library into alternative distributions easier. Brett has more on this, but the essential idea is to compartmentalize the standard library out into a separate project within source control, and have other implementation pull/ingrate that. Anything that's Jython/CPython/etc specific would be marked/stored appropriately. For example, multiprocessing as it exists today is a CPython artifact, and not needed for say, Jython.
  • And then there was the packaging discussion. Rather then rehash everything that was discussed, I'll simply mention that I proposed a much simpler approach. Specifically, I noted that we should simplify the core of distutils, pulling in setuptools feature where appropriate, offer plugin/hooks where appropriate, standardize on a simple, extensible metadata format and remove any of the "non core" bells and whistles from distutils. In essence my argument was that things like RPM building, easy_install, virtualenv, and so on simply do not belong in core python, rather they belong outside of the core, where consumers/developers can tailor solutions to suit their needs. Ultimately disutils can help them, and make the APIs/Plugins/Metadata standard but it should not be a fully fledged "package manager" or build utility.

Ultimately, the summits were a ton of fun, and being lucky enough to be invited was really great for me. At the end I was worried about people being tired of my chirping up, but it was resoundingly a success.

The conference

This is where things begin to blur - hopping in between hotels, lightning talks, hallway discussions - it was insane. Add to that my fear/stress about both of my talks, and I simply can't fit everything that happened in my brain.

I think I started the day in "How to Give a Python Talk" by AMK - which was great, if disheartening simply due to the fact that I had made some of the mistakes he pointed out in my talks. Ergo more slide hacking. After that it was hallway discussions and hitting up "How Python is developed" by Brett - I was going to heckle him, but I played nice.

Then there was the Python VMs panel, which I swapped out of and into the "Building an Automated QA Infrastructure using Open-Source Python Tools" - which can be summed up as "Yay buildbot" (I'm hard to impress, I've built a few of these by now). I then hit up the Twisted/AMPQ talk but ducked out early to go prep for my talk.

Then, it was my multiprocessing talk time. You can see the full video here, I think it went well, and feedback has been positive. Given I've done variations on this talk elsewhere, I was a little more confident in myself. I think I could have slowed down in some parts, and stopped fidgeting as well as a few other nits. I had some great conversations with users of the package as well as people new to it which pretty much absorbed all my time until dinner. I think I hit up the lightning talks - but I can't remember.

The next day, was the now infamous LINDBERG'D lightning talk (video here) - for those who don't know - Yes, Van knew - he even wrote the legal disclaimer I have in my slides. Basically, Brett and I had stayed up until what - 1am one night laughing about this idea of sending Van (who isn't very threatening) after commenters on the internet. The day after we stayed up laughing at this (much to the dismay of our neighbors) I hit Van up for some text and let him in on it. No, it wasn't serious (people asked). Yes, I was also voted in with a pile of other people into the PSF. Good times.

Afterward, the guidonote and then know I saw the state of django talk, as well as Jack's "Class Decorators: Radically Simple" - which was fantastic (although I saw a variation at the boston python meetup the week before). I dropped in on the ORM panel, and the GAE talk (which was disappointing). Then I hit Bob's "Drop ACID and think about data" which was awesome. I again ducked out to double check my stuff for my distributed systems talk. Also on saturday was the "Writing About Python" BoF, which was cool, but in which I may have over-expressed several cough strong opinions.

The video of my second talk is here. This one, my lack of confidence is apparent, and I'm still fidgeting. I think part of my problem is I like to express with my hands, almost like a spastic air traffic control man and holding the mic/trying not to fidget made my body just sort of spaz. This time though, I rushed from my talk into Alex Martelli's excellent "Abstractions as Leverage" talk. After that, more people found me and picked my brain.

I can't stress how awesome Alex's talk was - much of my hallway discussion time was spent discussing abstractions (especially around distributed systems) with him.

We'll see how my call for some cohesion and a real "django for distributed systems" call in my second talk goes. Everyone I have spoken to likes the idea and had a lot of great feedback, but lord knows I don't have the time to lead it up right now, maybe soon.

Late saturday, was the teach me web testing BoF which I ducked into, and then past that the Testing In Python BoF which provided me much in the way of fun, ideas, discussions and uh. Beer. Yeah. I can't exactly remember what I said when Titus put me on the spot to discuss "what sucks about testing in python". But I do remember having some great laughs. I think the heckling got recursive at one point, not sure though.

Sunday came, and with it, my sorry attempt to sit in the "Functional Testing Tools in Python" panel - which was thwarted by a 45 minute bloody nose. Apparently Titus talked a lot, so I don't think I missed anything. End of main con.

Before I move into the sprints - I want to point out that I had fantastic hallway discussions with tons of people - people I look up to, and people I've never met before. I had excellent lunches with groups of people ranging from the highly experienced to someone who has learned python a week before. I can't say enough about the simple fact that you get to relax, hang out and just talk with all of these people. Python is defined by it's community - and ours is pretty awesome.

The sprints

Monday morning, I was off to the python core sprint. I immediately started hacking on multiprocessing bugs - I think all told, I managed to close around 12 or so bugs by the time thursday morning came around. The sprint was awesome simply due to the fact I could look across the room/table and ask any number of core developers questions. Martin Van Loewis came to my rescue/aid a few times, and being able to bounce ideas off of everyone is pure unbridled awesome.

Having dedicated face to face time to beat on these bugs and share information/debate things is immeasurable. I also got access to snakebite thanks to Trent, who is still working out the kinks. Alas, even having access did not make cross-platform support (mainly the BSDs) any easier for multiprocessing. I spent a good chunk of my time futzing with virtual machines so I could do further work - I ended up cutting that short because I wanted to fix things at the sprints: not fart around with tool chains.

Other than hacking until late at night through the sprints, there's was quite a fun night where bourbon flowed, and many partook - much fun was had by all. There's nothing quite like having drinks and making awful threading/process/compiler jokes.

Bug fixes/patch work for multiprocessing:

In Summary

PyCon is simply getting better - I'm looking forward to Atlanta next year, if nothing more than for better weather. I got to talk to a lot of great people - Collin Winter, Thomas Wouters, Brett Cannon (be careful, he's an odd one), Guido, Alex Martelli and many others. Having many hallway discussions with language users and encouraging them to get involved - PyCon is AwesomeCon - no where else do you get to hear so much great information, discussions and points of view.

All of the videos for this pycon are going up on

It was a great time, and I can't thank everyone involved enough.