use Perl

Frozen Perl has come and gone, and I think it was a great success. There were no major catastrophes, nor any minor ones, really, and the feedback we've gotten has been very positive. We're already talking about doing this again next year.

This writeup is intended to help remind us what we can do better next year, and also to give people thinking of organizing a similar event some advice on how to do it. First, check out the writeup I did for the yapc.org site on planning a workshop. That will tell you how TPF can help you out, and give you some ideas of the basics you need to plan for.

First Things First - Venue

The absolute most important thing to do, as early as possible, is to book your venue. This was a source of pain for us, though the venue we ended up at was great. If you're planning to do an event at a university, see if there's a student group who can help you book the venue. We worked with the Bioinformatics group at the University of Minnesota, and as a result saved nearly 50% on the venue. This had a huge impact on our budget, as it basically saved us about 17% of our income!

Of course, you need to double-check things like audio-visual for your venue, though nowadays any new venue should have all the AV equipment you'd want.

Second Things Second - Sponsorship

The other thing that you can't do early enough is start contacting sponsors. If you're planning to keep the event very cheap, then you should plan to pay for most things with sponsorship. For our event, approximately 2/3 of the total expenses were paid by sponsors. Some sponsors will be very quick to respond, and some will take some cajoling. Another thing to realize is that you'll ask many, many more places than will respond. We contacted 30+ companies, and got 8 sponsors total.

Most of those sponsors were very quick to say yes. My conclusion from this is that your time is best spent contacting as many different companies as possible, rather than focusing on repeated contacts with a few.

If you're in the US, sponsors will be able to treat their sponsorship as a tax-deductible donation, though most of our sponsors didn't seem too concerned about this. Keep in mind that sponsors are getting something of value for their sponsorship, such as free admission and advertising. That should be accounted for in any thank-you letters you write.

Other sponsors may want to treat the sponsorship as a marketing expense, and as such may want an invoice for the full amount which breaks down the items they're getting. You can probably put things in this invoice like "20 free admissions", even if the sponsor isn't going to use them. They just want to be able to break down the expense in some way. Don't be afraid to ask them exactly what they want.

Budgeting

One initial mistake I made was to forecast our income and expenses for 80 attendees, assuming all 80 were paying. Obviously, this isn't the case, because organizers and speakers don't pay. We ended up with approximately 95 attendees, of whom maybe 80 paid. This includes a few day of registrations (5 or so). We also had 6 or so people who paid but didn't show up, but this didn't really matter for the budget, since we had already ordered their meals and t-shirts. It did mean the day-of registrees got lunch though.

Also keep in mind that with very low ticket prices, each additional attendee ends up being a net loss. Our expenses per attendee were close to $60 each, but the highest ticket price was $40. This wasn't a problem, but if we'd had 150 attendees, it'd would've been a disaster. Keep this sort of dynamic in mind when doing your budget forecasts.

Here's the final budget breakdown for the curious:

Income

Registration fees: $2,190 - a few folks opted to pay more than the ticket price, though that only added a $100 or so to this amount
Sponsorship: $5,000
Total: $7,190

Expenses

Venue: $1,250 - this was really cheap for such a nice venue
Event catering: $3,290.04 - included a continental breakfast, sandwiches for lunch, and an afternoon snack
Wireless access for the event: $0? - we may be getting this for free, otherwise it'll probably be around $200
Hackathon venue: $357.15 - included a $107.15 for internet, yeesh
Hackathon food: $245.15 - included a surpsising 20% service charge
T-shirts: $871.10 - these were 4-color silkscreens on black, American made (aka no sweatshop) shirts
Saturday dinner: $200 - I paid for everyone's appetizers and salads, knowing that we had a decent surplus
Total: 6213.43

This leaves us with a net surplus of $976.57. We'll probably do some sort of targeted grant with this money.

One thing to keep in mind is that some expenses may not be 100% fixed until after the event. For example, we paid for some of the food at the event based on consumption. It's a good idea to make sure you expect to have at least a few hundred dollars in surplus after the event.

Registration

ACT's registration process is damn confusing, though hopefully this will be fixed in the future. Basically, what it calls "registration" is the act of making an account or indicating interest in the event using an existing account. It is not paying.

We forgot to tell sponsors that if they wanted to use their free admissions, they needed to have people register in advance. We were fortunate that we had enough no-shows on the day of the event that we had enough meals! I almost forgot to account for our keynote speaker too, which really would have been lame.

Make sure that all of these people have accounts in the system and are marked as attending so that you include them in meal counts.

Random Notes

We were awfully late to make our shirt design, which meant a scramble to get them printed, and it also meant that Stephen Perkins had to pay for them out of pocket and get reimbursed by TPF.

We may consider closing registration a bit earlier next year to ameliorate this problem. We also did a bad job of making sure people got a shirt of the size they requested, and ended up not having shirts for some folks.

The lightning talks slide dance is a bit of a time waster. This year Ken put most of the talks on his laptop, but some folks had trouble using it cause they're not familiar with Macs. A KVM might be a better solution.

I hope all this information is useful to anyone out there planning their own event.

Something I've talked about recently with a few folks is that TPF has "too much" money. Specifically, TPF has reported an increasing balance at the end of its last couple fiscal year. Nonprofits are not supposed to consistently make a profit (no kidding), and this has a bad smell. I don't think there's anything fishy going on, mind you, it just doesn't look right.

Part of the problem comes from a large $35k grant paid to TPF by NLNet for Parrot. TPF got the money from NLNet back in 2005 (IIRC) and it took a while before that money started flowing out of TPF.

In discussions with a couple folks in TPF, they've said that they'd really like to spend the money, but they don't have avenues to do so. As most folks know, conferences and workshops are generally profitable for the organization (Frozen Perl netted around $1k) so that's not a way to spend money.

Then there's the grants program. I'm on the grants committee list and I've seen all the grants that've come through for the past couple years. The problem with the grants system is that there's not nearly enough grant applications coming in. Then of the applications that do come in many are simply unrealistic. Either they are too vague, too niche, or too hard, and so don't get approved.

I've been thinking about this recently and I think that this failure mode is basically built-in to the current grants system. First, TPF has a sort of unwritten rule that it won't fund travel, because there are so many Perl folks who'd like to go to so many Perl events that it would be hard to handle. I think there's definitely some truth to this, though I could see a use in funding travel specifically for project hacking (which TPF has done from time to time).

Another unwritten rule is that individual grants will not be more than $10k. This also makes sense, as $10k is a lot of money to give to one proposal. So what's the problem?

I for am unlikely to ever apply for a grant under the current scheme (ignoring the fact that I'm ineligible because I'm a grant manager), even though I could probably come up with something TPF would be willing to fund.

The problem is that I just can't see how a grant could be an incentive for me. I already put a fair bit of my time into FS/OSS projects just because I want to do so. I'd love to put in much more time, but I have things like a mortgage and family to consider. Realistically, the only way I'm going to put more time into my projects is to take a sabbatical from work, or at least work part-time for a while.

But if you look at the work/money ratio for past grants there's no way that could happen. Even if I aimed for something like %60-80 of my current FT income, a grant could not come close. It'd be more like 20-30%. So the grant provides no incentive for me. I suppose I could still apply for one anyway, but I don't feel right about that because it would just be funding work I would do anyway!

I'm sure many other developers have the same issue. So what is the point of the grants program, if not to make work happen that wouldn't otherwise happen? The acknowledgement of one's work is nice, but I already get that in many other ways, and if I'm looking for acknowledgement in the form of cash, I'd expect a heck of a lot more than a couple thousand dollars (Amazon and others, contact me privately for an address to which you can mail a big fat check).

Personally, I'd be perfectly happy to see TPF fund three months of full time work on any Parrot, Perl 5, or some other project likely to be of great benefit. Of course, the number of people eligible for this sort of grant are few in number, but it might achieve more in the long run.

I guess before that there was just a formless void with no time, no past and no future. Ok, maybe not, but no DateTime.pm for sure.

I realized that the 5 year anniversary of the Perl DateTime Project passed by recently. I date it this post to the datetime@perl.org list I made on January 9, 2003. That really got the ball rolling, and I was actually working on the first version of DateTime.pm in the next day or two.

Thanks to everyone who's contributed over the years. I don't think we realized that we'd end up creating _the_ definitive set of Perl date/time libraries, to the point where a _lot_ of people say "oh, I just use DateTime for everything".

Even better, I think we still have one of the best date/time library suites of _any_ language out there. The only thing I've seen in all this time that comes close is the Chronos library for Smalltalk, myself. Of course, if someone wants to point me at one they think rocks, I'm happy to learn more.

Our call for lightning talks is open. Ken Williams is going to be organizing it (thanks, Ken).

Also, Saturday is the last day to get the $20 early bird rate for non-students, so now's the time to sign up if you haven't yet done so.

The Frozen Perl 2008 deadline is coming up. I wrote some text that I've been asking folks to forward to their internal work email lists. If those of you out in use Perl land who are reading this could do the same, I'd be most grateful.

The early bird deadline for Frozen Perl 2008 is fast
approaching. After midnight Central on Saturday, January 12th,
the rate for non-students will double from $20 to $40.

Frozen Perl 2008 is a one-day Perl workshop happening on
Saturday, February 16th, with a great schedule of speakers. The
theme is "Perl in Practice", and there are a lot of great talks.

We have two tracks of talks. For folks new to Perl, there is a
strong slate of talks for beginners, including introductions to
OOP, testing, and more. For more experienced Perlers, there are
talks on Moose, Catalyst, and all sorts of interesting Perl
wizardry.

Registration includes breakfast and lunch, and possibly a
t-shirt, all for the ridiculously cheap price of $20. If you're
coming from out of town, there is a group rate at the nearby Days
Inn. There will also be an all-day hackathon on Sunday, February
17th for the true geeks.

For more information, check out the website at
http://www.frozen-perl.org/. You can sign up online, so don't
delay.

We hope to see you there.

Dave Rolsky
Frozen Perl 2008 Organizer

I've been the Parrot Grant Manager for a little over two years now, and that gives me an interesting position to observe its progress. I'm not really involved in the code side of the project, but I do pay attention to developments at a high level.

To be honest, most of the time as the grant manager was somewhat depressing. Not a lot seemed to be getting done, and I couldn't authorize any milestone payments. That in turn made us look bad in the eyes of our major funder, NLNet.

In the past six months or so I've seen a really amazing jumpstart of the project. A lot of credit for this goes to Allison Randal. She came up with a very aggressive schedule (towards the bottom of the page) and has been sticking to it, and I think her energy and hard work is motivating others as well.

For the first time in a while, I actually feel like Parrot is more than just a cool idea, it's a project that's going somewhere.

I'd also like to point out that there is some money available for people who work on Parrot. If you take a look at the schedule there are lots of milestones in the future. Many of them have Allison's name next to them, but I'm sure she'd be happy to have others pitch in. Each milestone is worth $2,000 on completion.

We've published a preliminary schedule for the Frozen Perl workshop. I think the schedule looks great, and I'm quite excited about it.

A few days before our call for speakers ended, I was feeling a bit panicked that we wouldn't have enough talks, so I harassed everyone I could to submit talks. We ended up with way more submissions than we could schedule, which is great for us, but I feel a bit guilty now.

I've also opened up registration for the workshop. The early-bird rate is $10 for students and $20 for everyone else. That rate will double on January 12. To register for the conference, you must first log in to an existing conference account (from YAPC 2007, for example), or create a new account. Once you are logged in you can pay for the conference online.

There's a little more than 24 hours left in the Frozen Perl 2008 Call for Speakers. If you've been putting your submission off to the last minute, that last minute is fast approaching. Submissions close at midnight (America/Central) on Tuesday, October 23.

If you're on the fence about submitting a proposal, we really hope you do submit something. More proposals gives us more choice, and we really want to encourage new, interesting topics, and new, interesting speakers.

I know all of you out there are enjoying making us sweat by waiting til the last moment, but the last moment is approaching. If you haven't yet, check out our Call for Speakers, and submit your talk soon!

I've been working on a rather huge revision to my VegGuide.Org site for at least a year or so. It started as a rewrite of the UI, but ended up becoming a switch to Catalyst and a UI rewrite and a bunch of new features. Talk about scope creep!

The funny thing about this is that it has defied the common wisdom about projects in a couple ways. First of all, the scope creep isn't really a problem, because I have no deadline. In the end I'll have a better product, it'll just take longer to get there. Ok, that doesn't defy common wisdom, exactly, but it's interesting to me that there are projects where scope creep isn't a killer, and the creep hasn't been demoralizing, since it's almost entirely driven by what I want.

The other funny thing about this project its lack of tests. When I started the move to Catalyst, there were no tests, and I've written a few along the way, but I'm not sure if they even still pass. I admit this somewhat shamefacedly becase I've been a big advocate of testing at my @DAYJOBS.

This is not a tiny project. I have about 16,000 lines of code in modules with almost no docs to speak of (another "mistake"), though that doesn't exclude whitespace. There's also about 6,000 lines of Mason templates.

I've been thinking about this for a while, and I realized that what makes it work is that I have written every single line of code in this project, so it all makes sense to me. I also have a decent memory for code, and I wield a mean grep.

I'm not claiming it's bug-free, but the bug count is surprisingly low given the large amount of code churn. I've never been afraid of refactoring this code base, and this project is basically a 50% rewrite, as I'm rewriting the controller and view layers from scratch. The model has changed, but mostly in an evolutionary way when I add new features or remove dead code. The underlying architecture of the model has remained the same, intentionally, since a 100% rewrite is too overwhelming.

There's no free lunch, however. Without tests, I really can't afford to let another programmer make major changes to the code base. Not only would they be more likely than me to introduce bugs, as the code became less a product of one person, I'd be more likely to introduce bugs.

The common wisdom is right. Tests do prevent bugs, and they're incredibly crucial in multi-person projects, especially when you expect to have turnover in developers, which of course you will on any long-lived project. But it's still funny for me to realize that I've been able to get away without them for so long. I don't know if I'll ever write any serious tests for this code, though maybe that will happen if I decide to make major changes to the model layer.