Tag Archives: austin

This week we did ApacheCon in Austin. I shipped the original Apache feather to the venue for 20th birthday of the Apache web server project, and it hung above the stage for the keynotes.

It’s an item that we’re very proud of, and of some historical significance.

The conference producers treated it like it was the Declaration of Independence or something. They handled it carefully and reverently.

At the end of the event the guy in charge of A/V came to me with some twine.

He said he had removed it from the hanging hooks on the feather in order to use black nylon that matched the stage dressing, and which would hang more securely. But he saved these scraps of twine because he knew how significant the item was to us.

Now, it’s not that the twine mattered – it was something I added years after the original was made. It’s that he cared enough, and respected our heritage enough to save it and track me down, that impressed me so very much. It really put a wonderful final touch on an almost-perfect event.

And this is why, among many other reasons, we love our conference production company, The Linux Foundation.

It’s only 8:30 local time, but I’m pretty wiped out. Day one has been amazing.

The morning started with the keynotes, which included the State of the Feather, with Ross Gardler, two sponsor keynotes by Mike Maxey (Pivotal), and Chip Childers (Cloud Foundry), and then the main opening keynote by Brian Behlendorf. Brian has long been someone that I’ve really looked up to, not just because he catalyzed the Apache web server project, but because of the deep thought that he’s given to issues around Open Source, community, and our role as responsible members of the human race. (Videos coming soon of all these keynotes.)

Right after the keynote, I moderated what I’ve been referring to as the “grey beard panel”, where several members of the original Apache Group (Jim Jagielski, Dirk-Willem van Gulik, Randy Terbush, Brian Behlendorf, Roy Fielding, and Ken Coar) reminisced about how things were in the early days, what mistakes were made, what things they might have done differently (SSL was a big item on this list), and other related items.

I’ve long joked that I do ApacheCon so that I can travel to exciting places and hang out on stage with my heroes. This was definitely one of those moments.

Then we had the reception at Old School, which was very nice, if a little loud. And now I’m back in the hotel room trying to decide whether to catch up on email, or go seek out some more social -ness. Probably go with the former and go to bed early.

We just got done with ApacheCon Europe in Budapest last week – http://apachecon.eu/ – and it’s time to start thinking about ApacheCon North America.

We’ll be holding ApacheCon North America, April 13-17th, 2015, in Austin, Texas. The call for papers is already open, at http://apachecon.com/, and we are hoping that this event will represent the breadth of the Apache Software Foundation projects.

Organize your community

The most important thing at this stage in the process is getting the Apache community involved in this event. ApacheCon exists to unite our community, get various projects to interact with one another, and bring new members into our community. The best way to accomplish these goals is to ensure that your project has representation at ApacheCon. Here are four specific areas where we need the help of Apache project communities:

Track layout

We’ve found that the very best way to have a project well represented in the content tracks is for someone deeply familiar with the project to craft an ideal track schedule, and then solicit speakers for those sessions. This has two immediate benefits.

First, it goes a long way to ensuring that the topic is covered with the breadth that it deserves, rather than having a few random talks that cover random esoteric parts of the technology, and ignore segments of the audience that you most want to attract.

Second, it is very encouraging to first-time speakers. It’s very difficult, and very intimidating, to try to come up with a topic to speak about the first few times. Seeing a list of proposed topics is the perfect way to say to a new speaker that what they know about is worth them proposing to a conference. “Hey, I could speak about that, and nobody would think it’s a stupid idea.”

Speakers

Some talks require certain speakers. You know this a lot better than we do, because it’s your project. We need your help to go to those specific speakers and encourage them to submit the specific talk(s) that you know they’ll shine at.

Reviewing and Scheduling

Once the talks have been submitted, we’re going to need your help reviewing them and building the schedule. To help with the review process, you’ll need to create an account in the CFP system (if you haven’t already done so) at https://identity.linuxfoundation.org/user and then email me – rbowen@apache.org – with your username, so that I can get you added to the review system. From there, you’ll see a list of talks to consider, and you can rate them according to how well you think they’ll fit the conference.

Of course, if you specifically solicited those talks, then you’ll quickly mark them as “Strongly Accept” with a comment of “I solicited this specific talk”, and move on. (The CFP review interface is at http://events.linuxfoundation.org/cfp/cfp-list if you already have an account.) You can review talks from other topics/tracks, too, if you feel that you have some domain knowledge.

Once the review process is complete, we’ll select the talks that rate the highest, and at that point we’ll be back in touch with you to help us order them correctly. Here, again, if you’ve already approached us with a layout of your ideal content track, there’s really nothing else to do. But if there are other talks that made it in through the review process, we’ll need help.

Hackathons

A key benefit of ApacheCon is getting your developers together in one place to work on things. We’ve got a a general hackathon area where you can gather to work on bugs, features, documentation, or discuss thorny community issues. (Don’t forget to summarize your conversations back to the mailing list for the people who can’t make it!)

If you want to have a sponsored hackathon specifically for your project, we can find room to make that happen. Just get in touch with me, and we’ll work out the details.

Talking before the event about what you’ll be working on has a number of benefits.

First, it gives people time to think about how they can contribute, and plan accordingly.

Second, it encourages people to come in from the edges of the project to participate more fully in the life of the community, because they can select something that they’re particularly interested in, and work on it in company with the rest of the project members.

Using the ApacheCon wiki – http://wiki.apache.org/apachecon/ – as a place to work on your hackathon topics gives conference attendees an easy way to find topics that they might be interested in, and connecting with the community. If you don’t have write permissions to the wiki, send me your wiki username, and I’ll get you added to the access list.

Sponsor

Your company uses Apache software every day. Perhaps you even contribute to a project as part of your day job. ApacheCon is the best place in the world for your company to show off their involvement in Apache, and to find new talent to work on their products. Sponsorship of ApacheCon gives you a platform from which to talk about what your company does, and gets your company name recognized – and closely associated with Apache – by the people that make the decisions in some of the most important places in IT.

If you’d like to sponsor ApacheCon, get in touch with me, and I’ll get you a sponsor prospectus, and help you select the sponsorship opportunity that’s right for you – whether that’s the conference lanyard, an evening reception, the conference bags or tshirts, or a booth in the exhibit hall. There’s something for every budget and level of exposure you’re looking for.

Get the word out

You have the ear of your project community – both the developers and the end users. We need your help telling them about this event. Right now, we need you to tell them to save the date. Later on, we’ll need you to be telling them about specific talks that will be of interest to them, both directly relating to your project and about other related projects that they should know about.

This is critical – it does no good putting together a great event, if nobody comes. You know who needs to hear the message, and you know where they hang out. A well-placed message by the trusted members of the community is far more effective than a dozen mass emails from a stranger.