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. DjangoCon.us is in the middle — it is organized for profit by a commercial entity, but it also contributes heavily back to the Django Software Foundation. DjangoCon.eu 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 DjangoCon.eu, 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.

So — my goal of the lightning talk was to say thank you to the python community, not only from me, but from the point of view of the company I work for (Nasuni) which recently launched. Thanks can be given back to the community in a variety of ways — money, code, sponsorship, programs, etc.

Sometimes, a simple Thank You can be a good start, and that was my goal. Unfortunately, I also completely deleted my slides (intentionally, what was I thinking?) after my talk was done.

What is Nasuni? We’re pretty small — obviously much smaller when starting (5 core engineers). The goal was to build a simple to manage, secure, reliable cloud-storage backed virtual storage appliance. Everyone helped code and design the product. We had to build it fast — when you’re a startup on VC money, you’ve got to be fast — you have finite time. Limited time, money and people.

From a technology standpoint — it simply made sense to put the core data path in C and C++ — you need speed, security, and the compactness C offers you when you’re talking speed. Not to mention, this is a device which has a finite amount of space, so keeping it relatively compact is a Good Thing. So the brain and central nervous system are in C — but we’re lacking something:

The rest of the person. D’oh. You know, arms and legs and stuff.

Let’s look at all of the other stuff we needed:

• tests
• tools/glue scripts
• prototypes
• user interface(s)
• other system daemons
• infrastructure
• web site
• deployment tools

And that’s just the stuff I could think of off the top of my head right now. So, we needed to compliment our super strong core with something pretty flexible, something that could also easily mesh with the core system as well.

When picking the technology; we needed speed of development, a broad ecosystem to build from, and it needed to ramp up and down. It had to be flexible enough that anyone involved in the project could become immediately effective with it.

Enter Python.

“Duct tape is like the force. It has a light side, a dark side, and it holds the universe together.”

Python Ramps “up”, and it ramps “down” — it’s good for “hard” programmers, and people just trying to get things done. It’s simple enough that anyone who has scripted in the past can get something done, and quickly. My motto has slowly become “there is no such thing as bad code — there’s just code that works, and code that doesn’t”. Code that comes out of someone who is just learning, and gets the job done is just as valuable as code that is well thought out and designed.

Python, and it’s broad ecosystem. It’s the glue, the face, the hands, the legs. It, plus insanely smart engineers let us move quickly, adapt to anything that popped up and put together a kick ass product.

8 months.

With Python’s help, we put together a ready-to-ship simple to manage, secure, reliable cloud-storage backed virtual storage appliance. 8 months! This isn’t a web app, or a another web service. This is something just shy of putting actual hardware into a datacenter! We’ve got python deep in our DNA. (And heck — the president of the company wrote a good chunk of it! How awesome is that?)

The moral of the story, however brief it is — when you need to sell Python to your boss, or that client — or if you’re just starting out. Don’t sell it with words. Sell it by showing it’s effectiveness, it’s speed. Just do it — that’s what Python is here for. helping you get your job done and succeed.

Python is not meant to be the prettiest, or the fastest-to-run, or the one with the latest feature du-jour. It’s there to let you get your job done. That’s why I love it, and much of the community around it — it’s the pragmatism, how will this let people be effective.

I wanted to take a moment not just to cheerlead — but to also specifically thank the projects and tools out there in the community that helped us get the job done.

• Python (duh)
• The Python standard library: This can not be stressed enough! Despite anything else we use from the ecosystem, the standard library is rich enough that it’s a massive time, and life saver. This is why I don’t believe that “getting rid of it” makes any sense at all. Python’s success is not just a by product of the language itself — the standard library is such a big selling point it can’t be stated enough.
• Django
• Virtualenv / Virtualenvwrapper
• Nose
• pip
• fabric
• paramiko
• lxml
• pycurl

And many, many others (including obviously non-python projects). Thank you, thank you, thank you!

In closing — Thank You!. Without Python, as a language — Python as a community, Django, and so many others — we would not have been able to achieve our goals. There’s so much to be proud of as a community, and sometimes we loose sight of it while debating frameworks, this, that or the next thing. Python is the perfect secret weapon for people and companies just trying to get things done

Thank you all — hopefully we can give back as much as we’ve gotten.

First up — early bird registration is open — early bird reg nets you a decent discount on registration fees for PyCon, and will run until January 6th.

Next — for those of you who didn’t see the news, Mark Shuttleworth will also be doing a Keynote at PyCon — this is awesome news. I think both keynotes, his and Antonio Rodriguez’ will be great. I don’t want to speak as to the content just yet — but with two high caliber entrepreneurs/founders, I’m dead sure it will be awesome.

As for the talks I want to see — well, this is criminally difficult. I pretty much want to see almost every single invited talk we have (I’m especially excited about Alex’s, Jack’s, Joe’s and Ned’s talks. I think our invited speakers this year will be very, very popular.

As for talks that “made it through the painstaking review process” I presided over, here’s my personal “gotta see” list:

• “Understanding the Python GIL” — David Beazley; David’s been hinting at taking his talk he did earlier this year “up a notch” — I can’t wait!
• “Actors: What, Why, and How” — Donovan Preston. Hell yeah!
• “Turtles All The Way Down: Demystifying Deferreds, Decorators, and Declarations” — Glyph Lefkowitz; Glyph is a fantastic, and energetic speaker. Definitely looking forward to see this dog-and-pony show.
• “Using Django in Non-Standard Ways” — Eric Florenzano; I’ve been doing a fair amount of non-standard Django work lately, and I’m interested to see things which may apply to my day-to-day work.
• “Modern version control: Mercurial internals” — Dirkjan Ochtman and “Hg and Git : Can’t we all just get along?” — Mr. Scott Chacon; these both apply to a lot of the work I’m doing (not the day job) and given the adoption rate of both mercurial and git, and the fact git continues to fill me with a seething rage every time I use it, I desperately need to see Scott’s talk!

That’s a quick top five (six) off the top of my head — and I could probably list out a heck of a lot more. I’m completely jazzed about PyCon this year. We’ve added a fifth track, we’ve got poster sessions, kick ass tutorials, fantastic talks, and rocking Keynotes.

So why haven’t you registered yet?

http://us.pycon.org/2010/conference/talks/

My thanks go out to every author, and person involved in getting us this far. With out the hard work of a lot of people, this would not have been possible.

This year is a bit different for me; this year I’ve taken the torch of Program Committee chair from Ivan Krsti? — this means I get to “lead up” the committee in reaching out for talks, reviewing proposals and choosing the content all of us will be privy to. This isn’t a job I take lightly; having been both a speaker and a critic of content in the past, I’m very sensitive to the quality of the talks we get at the conference. That being said…

PyCon 2009, by most measurements was one of the most successful and well-run PyCons to date. I met more Pythonistas in the week-and-a-half I was there, had some of the best conversations and went to some of the best talks I’ve had the privilege of going to ever there. I was lucky enough to also stay through the sprints for the entire time, and had one of the best times I’ve ever had coding.

PyCon 2009 was an interesting animal — despite most of the world being sucked down by an economy doing it’s best boat anchor impression, and with many conferences simply closing down entirely — we still managed to get around 900 people to come, which is simply amazing.

That all being said — I think PyCon 2010 can be better. In fact, it’s my firm belief that a little competition is good, and there’s no better competition than trying to one-up something you’ve done in the past. So, not to diminish what’s happened in the past — but let’s kick our own ass. Let’s make PyCon 2010 better — and ultimately that requires you.

PyCon is a volunteer run, volunteer made, volunteer speaker conference. It’s up to you, me, and everyone within the Python community to make this thing a success. Every speaker, every reviewer — every volunteer down to someone who helps bag t-shirts the night before help make this one of the best conferences out there.

This is a call for you yes, you to step up and help PyCon 2010 kick ass. Think you have an idea for a talk? Submit it. Seriously. Even if you’re nervous, a first time speaker, or you’re unsure of your topic — our crack team of reviewers (which you can also be one of) will help you massage and improve your submission.

If you want to have some pointers on how to make your talk better — check out out this video (a talk on… giving python talks!). Better yet, hit up pycon.blip.tv and watch some of the talks from the past.

Some potential talk topics I’d personally like to see are:

• Deep dives into more-advanced parts of python (a great example is Raymond H’s “Core Python Containers” talk”)
• Python 3 stuff — importlib, handling bytes vs. strings, etc.
• Idiomatic/optimized Python code (“make my code better”)
• Testing(and testing with) Python (I think michael should do a talk on all the new UnitTest stuff he and others have done)
• Cloud computing infrastructure — not “using” the cloud — more “building and deploying the cloud”. Something which comes to mind is a talk on Fabric.
• A talk on pip/virtualenv
• How to contribute to Python — and avoid Lindberg’dification (I suspect that’s not a word)
• Getting $THING done with Python — one of the key draws of Python, and what makes me so passionate about it is that it simply lets me get things done — what have you gotten done with Python? Most of all — how did you do it? What did you use?

Again, personally — I’d rather see less “we did this cool thing” and more “this is how we did this cool thing. I know that’s a tall order for what can be a short window of time, but supplement it with downloads, blog posts — give people something that they can take home and do.

If you don’t feel comfortable doing a talk — maybe you’re better off being a talk Reviewer. Talk reviewers are responsible for helping talk submissions by asking questions, making improvement suggestions — and they ultimately decide what talks everyone is going to see. They help make-or-break the conference as a whole. It requires reading, and a willingness to discuss — I know everyone out there can do that, and we need people with all types of skills and backgrounds to help us make sure everything gets a fair treatment and representation. Again, see this page for how to become a reviewer.

If you don’t feel comfortable with doing a talk, or reviewing — check out the “Helping Out at PyCon” page for other ways of helping. We need session runners, A/V people, people to man the registration desk; everything. Check out the staffing page for slots we need to fill!

Finally — if you don’t do anything else: Come. Bring a friend, bring two friends. Bring people who might only be vaguely interested in Python, expose them to this great community and the passion of it. Come for the talks, the open space discussions — and the simple opportunity to come and meet some of the brightest people in the community.

Then stay for the sprints; cause they’re damned useful and fun.