These tips aren’t meant to be exclusive to Open Source Bridge. We hope you will be able to apply some of them when you submit to speak elsewhere.

Have your own tips? Add them in the comments.

Read and understand our Call for Proposals

This falls under the general “know your audience” type of advice. Before you submit your talk, you should understand what type of content we’re soliciting.

Because we are trying to promote cross-pollination as well as provide space for in-depth discussions, our Call for Proposals is rather broad. We’re looking for:

• Useful recipes for software development, systems administration, and working with open source. (Cooking)
• Understanding how our systems work, in order to improve and extend. (Chemistry)
• Building open source businesses that thrive. (Business)
• Exploring how open source extends through technology into our communities. (Culture)
• Tinkering, experimenting and bending the rules to make hardware and software do what we want. (Hacks)

You can read more about our conference tracks here.

Look over previously accepted talks

You can get an idea of what we’re looking for by reviewing the proposals we accepted as sessions for previous years (2009 talks and 2010 talks).

Be specific, but also clear and concise

Let us know the question and give an idea of the answer. Make sure to give clear details about the content of your talk.

Write well and use standard English

Use proper spelling, capitalization, grammar, and punctuation. Use the active voice. Proposals without these things are difficult to read. Our content committee has a lot to read through; please don’t make this process more difficult.

Provide a good title

A title can make or break a talk. It should be concise, yet comprehensible. Clever, but not overly so. Sparking curiousity is good, but make sure people can tell what you’re going to be talking about. If your title accurately reflects both the subject matter and the tone of your talk, your ideal audience will find you.

Explain why you’d give a good talk

You don’t need to be an expert, but if you are, let us know. Don’t assume we’ll know who you are even if you’ve given a bunch of talks all over the world. Also don’t assume that we won’t pick you if you’ve never spoken. Have you given this talk at a user group with overwhelming success? Let us know in your proposal’s Note to organizers field.

Spread the word

Open Source Bridge allows public viewing and coments on all proposed submissions. Advertise that you’ve submitted a talk (we even have badges for this) so that people can comment and let our selection committee know they want to see your talk.

Ask questions

Not sure if your talk would be appropriate for OSBridge? Have other burning questions that are keeping you from submitting? The co-chairs and content commitee are available to answer your questions: content@opensourcebridge.org.

Practice makes perfect

One sure way to test a talk is to give it to a small audience first. These include your local user group, a brown bag session at your company, or even to a group of friends.

Hopefully these tips will help your chances in getting your talk proposal accepted. Don’t forget that the last day to submit proposals is Wednesday, March 16th.

So, that’s console-presenter and showoff, so far. I also know some very bold presenters use LaTeX with Beamer for theirs.

What do you use? And why?

(And while you’re here – Don’t forget to mark your favorite conference sessions to help us with scheduling! It’s easy – get logged in, and then just click on the stars next to sessions you like.)

Harvard Business just posted a piece bemoaning the state of the modern conferences and suggesting some ways to improve them.

We couldn’t agree more. And it’s nice to see the article reflecting some of the selfsame concepts Selena and Audrey have baked into Open Source Bridge, from the beginning.

1. Conferences and meetings should tell unique stories…. A conference should tell a story, one that unfolds and builds from the initial moments to the close. Like any good story, there should be moments of high excitement, followed by moments of relative calm. That’s different from panic and boredom in ceaseless alternation. A good meeting should make linear sense from start to finish, in a way that allows attendees to retain what they see and hear rather than just feeling overwhelmed by the information.

At Open Source Bridge, we started with a very specific story: trying to share the culture of being an open source citizen. And the conference tries to provide ways of experiencing that culture beyond sitting in sessions—from mellow to engaged.

A good example of that? Our hacker lounge will give you the opportunity to meet with open source citizens for hacking, chatting, or just hanging out, 24-hours a day—and it’s only a short train ride from the convention center.

2. Conferences should be for, by, and about the attendees. A meeting or conference should feel participative, and you, the meeting attendee, should have some significant part in it beyond being a warm body. Attendees should react, critique, judge, schedule, and vote for what they like and don’t like. And that’s just for starters. There are many ways to give attendees a larger role in meetings and conferences, from making them part of panel discussions to creating discussion groups to having them manage Q and A.

We tried to choose the best sessions that we could—but we also knew that getting a group of intelligent and passionate people would result in new ideas and discussions that needed a venue.

That’s part of the reason for the hacker lounge. It’s also why all day Friday will be in an unconference format.

See a session that you’d like to explore more? Set up a session on Friday. Is this conference missing a session you need to see? Plan it for the unconference. That’s why we’re giving you a whole day.

3. Conferences should be about more than just eating and sitting…. We live more and more of our lives in the splendid isolation of the Internet, with all the faux connectors like Facebook, Twitter, email, and the rest. Getting together is an increasingly rare and important privilege. Meetings and conferences should be constructed to take advantage of the gathered group. Every meeting or conference should use the power of the group to give something back to the community in which the meeting is held. Help a local charity, fix a local problem, champion a local hero, start a new movement. There are many ways one could imagine making use of the combined energies of the people assembled. It’s a crime to waste that gathered power.

You know as well as we do that this kind of activity is going to happen. It would happen in hallways, in sessions, and at coffee shops. That’s just how the open source community works. We get things done.

But we’ve tried to facilitate these interactions. We’re planning some activities to help stimulate discussions and solve some problems. But we’re also looking forward to seeing what happens when all of you get together.

Two weeks. Open Source Bridge can’t come soon enough. If you haven’t done so, please take the time to register. Or if you’re interested in helping, there’s a volunteer orientation tonight.

(Image courtesy Mr. Littlehand. Used under Creative Commons.)

1. Code: Add features and specs (tests) to the OpenConferenceWare (OCW) conference app. Join in if you have Ruby on Rails coding experience, such as contributing code to Calagator. See the task list for details.
2. Outreach: Contact user group leaders, educators, open source projects, mailing lists, etc to encourage them to spread the word about the conference and submit proposals.

We’ll meet up at Northwest Urban Grind at 10am. Later in the day, we’ll have a working lunch at the dining space between the Hot Lips Pizza and Laughing Planet at the Ecotrust Building. Join us for however much of this you can.

Thanks!

This past week, I attended PyCon 2009, which is the premier US conference devoted to the Python programming language. Held in Chicago, it was two days of tutorials, three days of talks (formal, lightning, and “open-space” unconference meetings), and four days of sprints. I attended the tutorials and talks, and also took the opportunity to advertise Open Source Bridge to the attendees.

Here’s some news from the conference that may be interesting to the the open source community:

PyCon had 943 attendees this year, which was a decrease of 10% from last year. The attendees discussed this a bit, and “the economy” was the only plausible cause that any of us could think of.

Are other conferences seeing the same year-to-year decline? If you know the attendance stats for another conference, please reply here with the numbers.

Mercurial was selected as the next VCS for the Python code base. Distributed VCS tools like Mercurial are today’s development zeitgeist, and with some good reason for large distributed projects. Python, like many projects, has used Subversion for some time, and the consensus was that it was time to move it to a distributed VCS.

The finalists were Mercurial, git, and Bazaar. Git was the first of the three to be rejected. Guido van Rossum, Python’s Benevolent Dictator for Life, made the final call to choose Mercurial. He hopes the pool will be switched over before the summer. (BTW, Mercurial and Bazaar are both implemented in Python.)

More Twittering as conference backchannel. At last year’s PyCon, IRC was used for all the backchannel communications. This year, Twitter moved into the backchannel turf — I observed a 40/60 Twitter/IRC split during the conference.

I found Twitter to be clumsy for conference chatting. My Twitter followers chose to follow me after appraising my tweets’ content and frequency. (Does John tweet about technical topics? About personal topics? Once a minute, or once an hour?) To suddenly change my behavior, and inundate them with meaningless messages, wouldn’t be cool.

OTOH, an IRC message is seen only by those in the channel when the message is sent. Yes, you can search for a message in IRC logs, but you’ve got to admit that reading old tweets associated with a hashtag is much easier.

So, it seems reasonable to tweet important announcements during a conference. Because they could be interesting to a broader technical community, and someone “dialing in” later can easily review them. But I didn’t care for those using Twitter for discussions and mundane announcements on the #pycon hashtag, nor the Twitter waterfalls displayed on the ballroom screen before the morning and afternoon sessions. (I already have Twitterific on my laptop, so I didn’t need to also see tweets displayed up on the big screen!)

Have you seen a change in Twitter use in the conferences you attend?

Regarding Python development, Guido will move out of the BDFL role over the next 5 – 10 years. Guido spoke for a few minutes about why we’ll be seeing this, and stressed that this should be seen as a natural result of the Python community’s growth. I think everyone was fine with this announcement, and I didn’t sense any undercurrent of concern in the attendees. He’s going to facilitate a succession in the language’s leadership, details TBD, so that one or more individuals can pick up the reins from him over time.

Guido has been the Python community’s technical, cultural, and organizational leader since he created the language. Time will tell how the shifting of responsibilities plays out, but I’m very optimistic the language community will continue to grow and thrive.

Also re: Python, expect less language development, and more development in stuff surrounding the language. Guido observed that the core language was now fairly refined, and suggested that new development energy would be better spent on technology surrounding the language. For example, on packaging and distribution technologies. In fact, Python packaging was a topic frequently discussed during the conference; everyone agrees that it ought to be easier, and a few ideas are percolating on how to streamline it.

That we can name a conference something a little awkward like “Open Source Bridge”, and no marketing department stops us.

There’s a project called Drizzle, that was forked from a commercial company and a team of what traditionally might be considered competitors ran with it. We can call a project PMS, and my friends will laugh but still review the code.

I’m running this conference because I love free and open source software. I want the way that we write code to dominate software development – I want it to become the default. I want “open source” to be synonymous with “software development”.

And of course, I think everyone should have the freedom to look at and tinker with the source code of the applications they depend on. Ultimately, we’ll prove that it’s better for society, even if we still have some learning to do around how to produce the best software, with the best user interfaces and documentation to go along with our code.

Which sort of brings me to why I think this particular conference is so important. The human aspect of software development — why we do what we do, how we communicate with each other and where we do our work are all critically important aspects of the open source ecosystem.

Portland is an amazing place – we’re overflowing with tech events every night of the week. I can’t keep up with our user groups because there are just too damn many of them. It’s amazing to see our community flourish, and we want to show you how we’re doing it.

Not just to show off. Well, ok. Maybe a little.

We want you to learn from us and go back to your town and start your own crazy tech scene. Set up calendars, meet up with people for lunch, dinner, beer and #afterhours hacking. Make spaces to create, express yourself and publish the code.

Do what we do. But not because I say so. Come see what we’re up to, first-hand.

(Image courtesy Aylaleia. Used under Creative Commons.)

Hacker lounge view of Portland, OR

We’ve been to any number of open source conferences. And for as much as we get out of the sessions, we always seem to get just as much—if not more—from the time spent with other developers.

Whether it’s camping out in the hallway, hanging out in coffee shops, or late-night code sessions at the hotel, spending time with other attendees working on projects—and reveling in being an open source citizen—is always one of the highlights of any conference.

So, when we had the opportunity to build Open Source Bridge, one of our primary concerns was that we had plenty of space for hacking. But we weren’t thinking a couch in the hall or a bunch of people crammed around the table. And we wanted our attendees to have something better than a desperate search for places with outlets, wifi, and space to code at 3:45 AM. We were thinking about dedicated space for hacking, 24-hours a day.

Introducing the Open Source Bridge hacker lounge, a space dedicated to code sprints, development projects, user-group get-togethers, and general hanging out—open all-day and all-night, throughout the conference. Perched atop the Hilton Portland, the hacker lounge will feature food, drink, interesting people, and plenty of space for various groups to gather.

Even if you’re not interested in hacking, you’ll still want to spend some time in the hacker lounge. From spectacular views of the Portland skyline to direct access to the best and brightest people, the hacker lounge is sure to be the crown jewel of the conference.

The hacker lounge is accessible to every Open Source Bridge attendee staying at the Hilton Portland & Executive Tower. So make sure you’ve got a room. If you’re interested in scheduling time for your group or project to meet, please contact us. We’ll make sure you have all the space, power, wifi, and sustenance you need. Interested in sponsoring the hacker lounge? We’ll be happy to work with you.

We’re looking forward to seeing you at Open Source Bridge—at both the sessions and in the hacker lounge. Make sure to register today and book a room. Have something you want to present? Our Call for Proposals is open until March 31. Submit your Open Source Bridge proposal today.

(Photo courtesy Hockley Photography. Used with permission.)

Say you were organizing a kick-ass conference that wasn’t focused on specific technologies or languages, but rather on being an open source citizen.

You’d want to contact all the user groups out there, and not just the local ones, hosted in your city, but the ones in other cities around the world. You’d want to get these people excited about your conference, and you know they’d get excited.

Why? Because your conference is different. It’s focused on open source as a whole, as the sum of its various parts, not on the parts.

You’d want to get these people excited, but you just can’t possibly reach out to everyone.

What do you do?

You put a call out to anyone who belongs to a user group and ask for help spreading the word.

This is that call for Open Source Bridge.

So, we spent all day Sunday, trying to contact as many user group leaders as possible, and not just the user groups focused on open source projects, but other groups too. After all, OSB isn’t just for open source developers. It’s also for people in IT too.

Problem is that we can’t possibly scale to reach every user group that might want to participate. We’re just humble volunteers, and we don’t have infinite time, sadly.

That’s where you come in, my new best friend. If you’re made it to here, you’re probably a little interested. Great. Do you belong to a user group? Even better. Would you mind mentioning our conference to your fellow members? Hmm . . .

What’s in it for you? Glad you asked. We’re offering discounted registration for people registering with the user group code, and we’re giving a free registration to each user group to raffle off to members. Fun, right?

Interested? You can find more details here.

The deadline to submit proposals is quickly approaching (ahem, March 31), so hurry if you have a great idea for a session.

Need more information or want to help more? Sweet, check out how you can get involved.

We really need and appreciate your help.

If you’re a student, you can register and attend Open Source Bridge for the low, low price of $99.

You read that right. $99 and all you need to do is show us your current student identification when you arrive at the conference.

Not a bad deal.

Photo by LWY on Flickr, used under Creative Commons

Since we began organizing the conference last year, we’ve had the help and advice of Bart Massey, an associate professor in the Computer Sciences Department at Portland State University (PSU). Bart was instrumental in helping us secure PSU as a sponsor, and he also supported our desire to keep the cost as affordable as possible for students.

We’re planning a conference for developers, by developers, and Open Source Bridge will be a three-day crash course in open source citizenry, giving attendees access to all aspects of open source through our famous five tracks: Cooking, Chemistry, Hacking, Culture and Business.

Say you’re a CS student. Chances are you know about open source and maybe you already contribute. Come to the conference, check out projects and meet the people who write the code. Find a project, or just dip your toe in the pool and see if you like it. (If you’re already swimming in open source and have a project you’re excited about, consider submitting a proposal.)

Say you’re an IT or IS student. Ditto. You probably know about open source. Maybe you don’t contribute, but you want to know what’s what because you’re smart and you know that increasingly, employers are evaluating open source for enterprise use. Here’s your chance to get an edge; come to the conference, meet the people who write the code, ask them the hard questions, watch and learn.

Say you’re a business student. You don’t write code, but you’ve got big ideas. You’re just looking for the right technical people to help you realize your vision. Come to the conference, check out the business tracks, and mix and mingle in the hacker lounge. Maybe you’ll find a startup partner.

Sound enticing? Don’t over-think it, register now, make sure to pick the student rate, and tell all your friends.

When we had our very first planning meeting for the conference, we made a big list of everything we wanted to cover (with colorful commentary—sorry, we were pretty excited).

Our initial conference content outline

In the course of the discussion, we realized that if every topic we were excited about had its own track, we would have way too many of them to manage. Also, it would go against one of our core principles: we want to bring people together, not shuffle them off into separate rooms. So we decided to take a different tack, and group the content around how we approach it, not what the underlying technology is.

That’s how we ended up splitting the most technology-heavy topics into three tracks: Cooking, Chemistry, and Hacks. I think they make the most sense if viewed as a group. We learn what to do via cooking, following recipes until we’re able to improvise our own. We learn why it works by studying the chemistry, which lets us see what’s happening at lower levels. Finally, we rewrite the rules by hacking. This isn’t a linear progression; we may jump from one approach to another frequently in the course of our work.

The other two tracks round out the picture. Business is about how we earn a living. Culture is all of the other things we do around our work, like organizing user groups, managing projects, and applying the open source ethos to other areas of our lives.

We arranged these five tracks to cover the full scope of our open source existence. Within them, there’s plenty of room to talk about individual languages and tools, even at the advanced level, but sharing with people from a range of backgrounds. We can all learn much from each other.

Hopefully, this provides a better frame of reference for our tracks. (And now you’ve got even more reason to submit your own proposal.)