Headed to OSCON

oscon-logoOnce again, time for the annual trek to Portland, Oregon for OSCON — perhaps for the last time!

Next year, OSCON is going to be in Austin, TX — which seems like a bit of a mistake to me. Portland and OSCON go together like milk and cookies.

If you’re going to be at OSCON, make sure to drop by Open Cloud Day on Tuesday, and come by the Red Hat booth to say hello!

Presentations and Sharing Slides

Warning: Massive generalizations ahead!

It’s pretty common for conference organizers and attendees to ask presenters to provide their slides after the talk to share/post on the event site. While well-meaning, I’m not sure this is an entirely positive trend.

A slide deck that stands alone is often a sign of a poor presentation. If I can read the slides and get a lot out of them without the presentation they accompany, odds are you could have just written a short post that would have conveyed nearly as much information without the need for people to sit through a presentation. (Much less travel a great distance to see it.)

As a corollary to the above, if the presenter is using slides that convey most of the information, then the attendees are probably spending more time watching the slides and/or checking their phones/laptops than actually paying attention to the speaker. Again, what’s the point of sitting through a presentation if you can just read the slides and get most of the information that way?

Yes, you can have meaningful slides that support a presentation and are useful afterwards. For example, if you’re doing a presentation with a lot of data/charts, having those to refer to after the presentation is a good thing. Having code examples, or follow-along examples is a good thing.

I’m writing this, of course, because I received a request for slides for a presentation I gave recently (at SCALE) and was thinking about how often I’m asked for slides before a presentation even begins. (“Will the slides be available?”) In this case, the presentation has some slides that will be useful for attendees — but a lot of the slides are just enough text to spark my memory for the next topic.

Sometimes I’m tempted to chuck presentation-ware altogether and just give a presentation from notes accompanied (when appropriate) with a demo. A live presentation should be about an experience that is more than a person droning on at the front of the room that adds little or no value to the text on a screen. If it’s not, what’s the point?

This is something I’ve been turning over in my head for a while, and I think one of my goals for 2015 is to raise the bar on my own presentations. Suggestions welcome!

Sharing Apache’s Goodness: How We Should be Telling Apache’s Story

ApacheCon Europe LogoThe Apache Software Foundation (ASF) gets many things right: its governance model for open source development has served hundreds of projects well. The Apache Software License (ASL) is one of the most successful open source licenses, well-liked by many contributors. But the ASF is not perfect, and it has a few areas where serious improvement is needed.

One of the areas is promoting the ASF and its Top-Level Projects (TlPs). The ASF has more than 150 TLPs, but the odds are most people in the tech industry have only heard of a few of them. The ASF itself is fairly conservative about telling its own story, and most of its TLPs are content to send out the occasional release announcement to their announce@ mailing list – with the barest of details, usually not even noting what the project does – and with no effort to reach out to the larger community via social media or by pitching press. (A wire release is not the same as actually pitching most tech press.)

Why It Matters

What’s the point in making software and then not telling anyone about it? It’s rare indeed for a project to be so mind-bogglingly good and relevant to users immediate needs that word-of-mouth alone can carry it to the full audience that would benefit from it. And, possibly, contribute to it.

It’s the contribute to it that really interests me. You see, Apache is voluunteers. Oh, sure, people get paid to work on Apache projects – but not by Apache. They get paid by IBM, Citrix, SUSE, Red Hat, Microsoft, and hundreds of other companies. Which means that when their $dayjob means not working on Apache software, they almost inevitably slow down contributions – if not stop entirely.

Volunteer contributions ebb and flow. The contributor who put in the most patches for the last release may not have time when she finishes her university studies and has to get a full-time job. The release manager for the current release is going to run out of time in a few weeks when he moves to a new job that doesn’t have anything to do with Apache software. The best contributor you’ve ever had hasn’t sent in a single patch yet, because she’s never heard of your project. You get the point – you need new users to become new contributors to become new committers to become PMC members, and eventually ASF members.

It also matters when it comes to finding donations for the foundation. Apache keeps growing, and the needs of its projects continue to grow. A few years ago a few mailing lists, a Subversion repository, and a Web site were enough to call it good. Now projects want Jenkins, code signing, git repositories (and migrations from Subversion), etc. Storage requirements grow every day. The number of commits grows every day. The number of tickets to Apache Infra – which is not entirely staffed by volunteers – will also increase.

It also matters because Apache does not only need to attract more contributors, but more diverse contributors. That’s a lot more than just publicity, but it’s an important consideration here.

Finally, we need to be promoting The Apache Way rather than becoming complacent. “Open source” (for certain values of “open source”) may have “won,” but The Apache Way certainly hasn’t. Throwing code over the wall on GitHub is no way to grow a community. There’s a lot more to it than that, which projects tend to find if they gather any sort of popularity and start hitting growing pains.

ASF Services

Apache provides quite a few services, including some press/marketing help – but we have one contractor for the ASF’s 150+ projects.

We need to think about how we assist projects in promoting themselves and the foundation.

Another problem: Right now, most of the ASF’s projects are silos. There’s damn little communication between projects, with some notable exceptions (e.g. the Hadoop family of projects). Sure, the ASF members from various projects communicate on some of the private lists, but there’s damn little collaboration between PMCs and committers.

We can do better, and we need to do better.

Marketing@Apache.org

One of the top things we need to do as a foundation is start focusing on publicity overall, and that means actually communicating. Right now, only three of the 150+ TLPs have a marketing list: CouchDB, CloudStack, OpenOffice. I’d wager than only a few actually recognize non-code contributions like marketing assistance as “merit” towards becoming a committern/PMC member.

A few weeks ago, I asked Infra to create a marketing@apache mailing list. There’s a press@ mailing list, but it’s private – only for folks working on marketing for the foundation, or members who’d like to join.

Press@ is needed for things that should be confidential, but there’s a whole host of conversations that can happen in the open. My hope is that folks interested in promoting Apache projects will join and start talking about how their projects can improve their promotional efforts and how projects can work together.

I also have a lot of ideas and suggestions how projects can improve their promotional efforts, but I’ll save that for another post later this week.

The slides from my talk at ApacheCon Europe are below. Have comments? Ping me on Twitter @jzb, or send me a note to my Apache.org email (also “jzb”).

Happy 21st Birthday, Slackware – and Thanks, Patrick!

Slackware 9621 years ago today, Patrick J. Volkerding announced the 1.00 release of Slackware Linux to the comp.os.linux newsgroup. As Patrick wrote at the time, “This is a complete installation system designed for systems with a 3.5″ boot floppy. It has been tested extensively with a 386/IDE system.” Times, and technology, have changed quite a bit — but Slackware continues to stay true to Patrick’s original vision and provide users with “the most ‘UNIX-like’ Linux distribution out there” with simplicity and stability “while retaining a sense of tradition.”

Slackware had just turned five when I first discovered it and, by extension, Linux. It was the first Linux distribution that I’d ever used and it was a wonderful platform to learn on. Made even better by the fact that Patrick was quick to respond to emails asking for support, and provided gentle guidance to updating XFree86 so that I could actually use X on my blazing fast Pentium 133MHz machine with eight whopping megabytes of RAM.

Slackware wasn’t quite the first Linux distribution, but it outlived its predecessors as well as many Linux distributions that came after. Slackware has not only continued to provide new releases at steady intervals year after year, but it’s done so with a fairly small (but mighty!) core team of developers led by Patrick.

If you’re in the Linux or open source community, you should take a minute today to raise a glass to toast the Slackware distribution. I’ll be hoisting a beer (though a better one than PBR…) to Slackware, and its team. Thanks for introducing me to Linux, for staying true to your vision, and for providing so many users with so much goodness over the years. Here’s to Slackware, Patrick, and all the other folks who’ve made Slackware great over the years – and to many more releases and birthdays to come!

[Link] The Compositional Nature of Vim

Nice piece on “The Compositional Nature of Vim” over on Ismail Badawi’s blog:

There’s a combinatorial effect here. If I know about o operators, m motions and t text objects, I can do up to o * (m + t) different things. Every new operator I learn lets me do up to m + t new things, and every motion or text object I learn lets me do up to o new things. Once you internalize vim’s language for editing text, then not only does editing text efficiently become easier, but you also start learning at a much faster rate, as every new thing you learn interacts with all the things you already know.

If you’re still learning Vim (and despite using Vim for ~15 years, I count myself in that group), take a few minutes to read (or at least skim) this post.

The Compositional Nature of Vim »

Upstream Podcast: Episode 6 – Interview with Marvin Humphrey at ApacheCon North America

Got a bit behind in editing, but here’s the latest Upstream podcast. This one features Marvin Humphrey of the Apache Software Foundation. Really enjoyed speaking with Marvin (on and off mic) and hope you enjoy listening to the podcast as much as I enjoyed speaking with him!

If you’d like to catch prior episodes, you can find all episodes listed on Red Hat’s community blog, or subscribe to the RSS / iTunes feed for Upstream:

Have thoughts on the podcast? Would love to hear them! Let me know who I should talk to, what kind of topics you’re interested in, and what’s good/bad about the ‘cast. Thanks!

Looking Forward to ApacheCon, CentOS Dojo Denver, and CloudStack Collaboration Conference in April

In just a bit more than a month, the mile-high city is going to play host to a triple-feature of open source IT goodness:

Starting April 7th and running through the 11th, you’ll have a chance to connect with folks developing and deploying some of the most used infrastructure in the world. Apache Web server? Check. Apache Hadoop? Check. Lucene, Solr, Libcloud, Kafka, Cordova…? Check, check… well you get the idea. Also CentOS and Apache CloudStack.

The schedule for each of these events is outstanding. Oh, and I managed to sneak in a few talks as well. I’ll be doing a talk at each:

You really, really don’t want to miss this year’s ApacheCon, and stay for the Dojo and CloudStack Collab because they’re also going to be chock full of goodness. You can register for ApacheCon here, and register for the CentOS Dojo for just $50 through March 20 and add the CCC registration there as well. Or just register for the CentOS Dojo on April 10th separately if you can only make one day.

Have questions about any of the events? Drop me a note by email or hit me up on Twitter, happy to try to help or find the right person.  Hope to see you in Denver!

FOSDEM Distributions Developer Room: Call for Participation

FOSDEM LogoOnce again, FOSDEM will have a cross-distribution miniconference on 1 & 2 February 2014. We’d like to invite submissions of talks, Birds of a Feather (BoF) sessions, or round-table discussions from any interested representatives of Linux distributions or individuals who have a topic of interest related to Linux distributions.

Proposals should be submitted through the FOSDEM proposal system (Pentabarf) here:

https://penta.fosdem.org/submission/FOSDEM14

You’ll add your session title, speaker bio, and abstract for the talk. If you’ve presented or submitted at FOSDEM previously, you should have an account in Pentabarf. If you haven’t created an account, but have presented at FOSDEM previously please contact me before creating an account – the odds are you have an account that was created previously by the FOSDEM organizers.

Deadline for submissions is 22 December 2013. Since we’re on a tight timeline, this is unlikely to be extended.

In addition to speakers, we also need one moderator for each day, and a video volunteer for each day. The moderator will introduce the speaker, keep time, and pass the microphone around for questions. The video volunteer will handle recording of sessions with provided equipment. (Don’t worry, we’ll also provide training as well.)

The call for participation is going out a bit late, so please do speak up quickly if you’re interested in participating! Also, please do help spread the word so we can ensure the best possible program for this year’s FOSDEM.

First Impressions at AWS re:Invent

Last year I attended AWS re:Invent, kinda, sorta. We were in Las Vegas to put on the first Apache CloudStack conference and most of my time and brainpower were consumed with last-minute planning for that event. I did spend time in the developer area, on exhibit floor, and some of the after-parties – but it wasn’t a usual conference for me.

This year, I’m actually not consumed with pre-conference planning (though the CloudStack Collaboration Conference is happening next week in Amsterdam, and I’m sad I won’t be able to attend), so I’ve been paying attention to re:Invent.

Generally, I tend to attend more community/FOSS and techie shows than big vendor blow-outs like AWS re:Invent. The very scale of the event is really impressive, and I have to give Amazon kudos for the slickness of the presentations and how smoothly the event is running. The registration, for instance, was totally slammed on day one – yet they kept the lines moving really well and even had a DJ (!) playing tunes in the corner to make the wait a little better.

The content on the other hand… well, it’s a bit generic and the keynote yesterday was definitely not what I was hoping for or expecting. First, I was surprised and disappointed at the amount of time Amazon spent calling out competitors (IBM, for an admittedly silly marketing stunt) and dissing private cloud. Does Amazon offer a solution that’s really appealing for certain applications or certain types of companies? Yup. Is public cloud ever going to be the majority of the compute market? I’m not convinced.

The keynote yesterday felt like a plea to enterprise, and way too much preaching to the converted and marketing fluff that we already knew anyway. Yeah, we get it: AWS is big, lots of customers (oooh, pretty NASCAR slides) and so forth. At least they did announce a few new services during the keynote, so attendees got a little excitement.

For me, the biggest part of any event is the “hallway track.” On one hand, it’s pretty good here because there’s about 9,000 people – you can easily find interesting people who are doing fun stuff with AWS and other tech, so that’s been good.

The bad, really bad, is the conference scheduling site is terrible and there’s no attendee directory whatsoever. I was doubly disappointed when I looked on Lanyrd and found only about 40 people signed up. It would have been great if I could have searched a directory (opt-in, of course) to try to connect with people ahead of time to meet and talk about their cloud usage.

Maybe next year. Overall, I think re:Invent is worth the time, money, and trip if you’re using AWS or are trying to disrupt AWS – but there are a number of things Amazon could do to make the conference more friendly for attendees and partners.

Four vs. Six Months

The decision to have time-based releases was made early on with the Apache CloudStack project. It’s fairly standard these days to go with time-based releases rather than feature-based releases, and makes a lot of sense for projects that are primarily aimed at use in corporate IT.

While coming to the decision of time-based vs. feature-based was easy, coming up with the actual length of a release cycle is trickier. Everyone wants the release yesterday, so there’s a strong desire to have a shorter cycle. But a shorter cycle puts pressure on folks to actually get the release out, and a shorter cycle (especially for newer projects) seems more difficult.

We decided initially to go with four-month cycles, but that decision is being revisited right now, with a lot of the community leaning in favor of six-month cycles.

I’d be curious to hear from other projects exactly how they came to decide the length of time-based release cycles. In Linux distribution circles, six-month cycles have been popular – though it looks like Ubuntu is fiddling with that a little bit, and AFAIK, Fedora has generally come closer to seven-month cycles when all is done and said.

For the record, I don’t think we’ve got enough data to decide that four month cycles aren’t workable. I’d really like to see the community take 4.2.0 as the cycle to really refine processes, get more automated testing in place, and try to get documentation folks working together a little better before saying that six-month cycles are a better fit.