Early morning thoughts on release management in open source communities.

I occasionally have days where, when reading a mailing list, I want to stab my eyeballs out at what I am reading.  And then I realize that: Perhaps my thoughts might be better utilized if I make a blog post.  (Bonus: I won’t look like a totally angry troll!) And then, at 4am, as I lay in bed, the thoughts still seething in my head, I say, well, maybe I’ll do that now.

And thus, today, I bring you: My observations and advice on the utilization of time-based schedules in open source software communities.

Full disclosure: I used to do program management (ie: build the schedule, kindly and repeatedly ask people to comply) for Fedora.  I learned a lot in a relatively short period of time, thanks to the awesome people I work with.  I have no certifications in project management, I have never officially studied it or taken a course in such things, and quite frankly, I just might not actually know what the hell I’m talking about.  But I like to think I know a thing or two, or that I might at least give you, dear readers, something to ponder on as you work in your own projects.

First off: There are time-based schedules, and feature-based schedules, and those are pretty much the two models I see employed in community-land.  (Yeah, yeah, agile, blah blah blah, I’m not getting into that or its relationship to these methods right now.) Time-based means that you do releases on a predictable basis, you pick a date, and you STICK TO THAT DATE, come hell or high water.  Feature-based scheduling involves identifying a list of features, and working until those features are actually done, at which point… you release.  I am not going to dive into the latter method, at least today, but I will say this: “Features” tend to suffer from what is referred to as scope creep – what seemed like a small task in the beginning gets a little enhancement here, a little extra love there… basically, they can go on for some time without being *done* according to someone’s opinion.  Which means it could be a really long time between releases.  (And that may be okay for a lot of people, but you lose out on some of the benefits I’m going to talk about.)

The benefits of time-based schedules

There are many, but these are the two big ones in my mind:

  • Out with the old and in with the new. If you’re doing time-based schedules on a short enough release cycle – 4 to 6 months, even 8 months – you know that anything that doesn’t make it into this release, is only going to be one more release cycle away, and you know exactly how long that will be.  You also benefit from looking like you’re actually making progress; potential contributors can see that things are coming out the door, and not wonder if the community they are about to jump into is ever going to finish what they are doing. Users know when new stuff is expected, also good.
  • Predictability for the community. If I know that I generally contribute to one specific thing (or perhaps more), and I know when that contribution is expected, I am more likely to make that deadline.  There is never any question about when things need to happen.

But announcing that the release date is X and patches are welcomed is, well, not enough.  Particularly if the scope of the project is large, or you have a large number of contributors. Here are the basic pieces that I think are important:


  • Have dates by which features must be proposed and accepted.  I’m not going to tell you how to decide what gets in and out; that varies from community to community.  MAKE SURE that this list is prominently displayed.  This gives people a way to give feedback. Sometimes features collide; this can help to avoid that, or at least, to ensure that changes are well-coordinated for things that are really dependent upon each other.
  • Have a date by which all features must be complete. You can scale this as you want (must be close, another date for really done). And then be very clear about the fact that features will NOT BE INCLUDED if they are not finished. Why? There may be people in your community doing documentation, marketing, translations, making test plans, etc. People need to know when a good time is to start doing all of those things, without doing it for things that are going to get dropped; they also don’t want to get hailed the day before release because this brand new thing just landed and HEY, wouldya mind dropping everything and writing replete documentation at the last second? Not cool. Having a clear cut-off is important.
  • Track the actual progress of accepted features. Make feature owners/contributors be responsible for providing those updates on a regular basis in an easy-to-read place.  Nobody likes surprises.
  • Define what a feature actually is. New and shiny stuff doesn’t have to be the limit.  Sometimes a feature can be a change in how the software is built, or the removal of some functionality or dependency.  Again, the key here is having the list of features published; removing things arbitrarily if people depend on them, or worse, if someone is actually contributing those things or would commit to improving them if they knew that there were issues that necessitated the removal, sucks.


After the point where features should be done, well, people are probably doing bugfixing for a while, and then testing and getting ready for release.  The length of time for all of these things is up to you; just be sure that, again, IT IS PUBLISHED AND KNOWN. But here are a few other things you can add to make the sprint to the finish line more efficient:

  • Have a list of release criteria.  Nobody wants to sit around arguing whether or not something is shippable. What functionality does the software ABSOLUTELY have to have to make it useful after shipping? Write it down. Make sure people are in agreement. Make sure your test plan actually tests those specific criteria.
  • Publish your test dates. Advertise them.  Make sure when you’re deciding these dates that it’s actually a reasonable amount of time to test things. Methamphetamines are illegal and bad for you, kids: don’t make your QA folks stay up 24/7 for a week.
  • Have a date on which key contributors/stakeholders/stuff-doers can meet or communicate and agree upon shippability.
  • If it is not shippable, have a pre-determined (as in: not during the meeting!) length of time during which bugs will be fixed and testing will happen before you meet again.

Some last bits of advice, at least for this blog post, for those of you who are just absolutely convinced by now (or were already moving that way):

  • Pick your date, and work backwards.  Figure out how much time it takes to reasonably test a final product, how long it takes to build a release candidate, how long you want to do bugfixing on features for before you make a release candidate, how long the development phase is, the date by which all features should be accepted and defined, how long your planning/feature proposal period is. And remember that it’s not all about the code; if you have people doing documentation, translations, etc. make sure that their roles are defined and considered as well.  And above all: Make sure people are in agreement when you’re doing this for the first time.
  • Bugs in the release process are expected. Especially the first time. Document them and fix them, yo.
  • PUBLISH YOUR SCHEDULE. Pro tip: Publishing your schedule on a mailing list and having it be the only place where it is seen is not helpful. Put it on a wiki, a webpage, whatever it is you have. People do not want to go trolling through their mail to find this when they likely refer to it often.  Newcomers do not want to search through archives in the hopes that it might be there.  Users don’t want to do that either.
  • Advertise your schedule at major milestones.  If you have a blog, a twitter account, whatever, NOTIFY people of looming deadlines and of actually reaching those milestones. If people look like they are falling behind, reach out to them personally.  You don’t want people saying, how was I supposed to know? Added bonus: you will look like you have your act together! (Even if inside you’re wondering deep down inside how the hell this is ever going to come together into something that resembles anything.)
  • Bugs. You have them. Remind people of their existence as deadlines loom. Paste the list and owners if necessary.
  • Haz too many dependencies and relationships between tasks? Taskjuggler, my friend. Use it.

And finally: If you are making the move — don’t magically cut over to a point that is skipping half of the steps above.  Seriously: If I’ve been steadily plugging away at something, and suddenly I have this major impending deadline out of nowhere that I can’t meet, or if I am a maintainer of some sort and I am suddenly faced with fix it or it disappears, that’s not a pretty feeling.  Time-based schedules can help to build your community by ensuring that people can be successful contributors to the project, which makes them come back to give more; it helps them to know when they can contribute, make changes, and helps them to prioritize your project amongst all of the other stuff in their lives.  Skipping key milestones, skipping listings of features or changes or agreement upon those changes, effectively prevents some people from being able to participate or contribute.  You can accelerate under certain circumstances – but don’t skip the meat of what needs to happen.  Good processes can help to build great communities, which can build great software. Don’t disenfranchise your contributors (who are also your best evangelists) – they are the ones who will get you through this release, and many after it, and make it better.

And now is the time where Robyn sleeps for a bit.

Fedora 17: The beefiest release yet. With a side of awwwwwwww.

For those who missed this morning’s beefalicious news: Fedora 17, “Beefy Miracle,” has been released into the world, ready for consumption by freedom-lovers everywhere.

You can read the full release announcement here, but that’s not what this post is about, really.

One of the things I truly, ahem, relish about our community is our ability to play well with others.  And I think we’re doing an exceptional job of that lately.  It’s easy to look at a list of features and say, “Woo! We haz something,” but looking at the ties and bonds we are making from the Fedora Project to other communities is what’s really impressive.  When you look at things like having JBoss AS7 in F17, or having the newest version of OpenStack in F17, it’s not just “in” — it’s really apparent that we’re not just packaging something up, but we’re building bridges between communities.  People who have never been exposed to Fedora before may take their first proverbial bite, so to speak, because of their participation in these other communities; conversely, people who have never used JBoss AS7, or any of the other of the number of projects that you see in F17, may finally give it a try, simply because it’s available, and it works.  It’s mutually beneficial, and, well, it’s just rockin’.

And for that, and for so many other things: I thank you all, for being stellar community superstars, for being amazing friends, for embracing others with open arms, for scratching that itch and reaching out to other communities, and for staying up all night (multiple times), and showing the world what the open source way is truly about.

In conclusion: I promise that no corn was harmed in the making of this blog post, despite apparent corniness levels. Corn can be used for corn dogs, who are relatives to the Beefy Miracle. And we wouldn’t want that.

Go out. Download Fedora 17. Enjoy this release.  Lots of mustard — and you know that that means progress. :)

We might be giants.

There’s a picture opposite me / Of my primitive ancestry / Which stood on rocky shores and kept the beaches shipwreck free

Though I respect that a lot / I’d be fired if that were my job / After killing Jason off and countless screaming argonauts

Bluebird of friendliness / Like guardian angels, it’s always near

Blue canary in the outlet by the light switch / Who watches over you / Make a little birdhouse in your soul.

I’ve been at SCaLE the past few days.  One of the things I love about regional Linux and F/LOSS conferences is the time I get to spend meeting other Fedora contributors that I haven’t met before, new potential contributors, and catching up with some of the people I already know.  Spot and I had a nice chat the other night, talking about Ye Olde High School things, and it reminded me of the blog post I’ve been meaning to write — which, friendly Planet folks, is what you are now reading.

One of my dear high school friends was our class Salutatorian.   His graduation speech: reciting the lyrics to “Birdhouse in your soul,” by the awesome They Might Be Giants.  It was a Totally Awesome Moment.  I still think about it fondly to this day.

I once was combing the Fedora wiki, looking for a banner of some sort or another, and came across some of the Fedora 12 banners, which featured blue birds.  I was immediately reminded of the “blue canary in the outlet by the light switch.”

Since then, I’ve thought a bit about it now and again, whenever the song comes up in my music mix.  The song itself, like so many other songs, is one of those, “What does it mean? Does it mean anything?” types of songs… but of course, now, in this age of intertoobz wonder, there are people who sit around dissecting songs FOR YOU! What a glorious thing.

So while I’m not going to go into gory detail (though you can certainly go read about it yourself if you want), I’ll give the 80-foot-view of what I believe to be the general premise of the passage I quoted above. Yeah, this blog post is TL;DR.  But I know you’re sucked in by now, so keep reading!

The voice of the song is a bathroom nightlight, shaped like a blue canary. Nightlights are friendly little things, particularly when you’re a child; they illuminate things just enough to see, essentially watching over you and protecting you.

The picture opposite the light, of his primitive ancestry? The one that stood on rocky shores and kept the beaches shipwreck free? A lighthouse.  (For some reason, people like the whole beach / lighthouse theme in bathrooms.)   He totally respects the lighthouse, but also understands, he’s not a  lighthouse; if he had to act as one, well, something terrible would happen, like killing off Jason and the Argonauts, since they wouldn’t be able to see by the light of a nightlight. [1]  But the similarity between the two is that they’re both beacons of light – one for the safety of people using the restroom when it’s dark, and one for the safety of sailors when it’s dark.

The metaphor? If Fedora is the Blue Canary nightlight in the outlet by the lightswitch – the picture opposite Fedora, of our primitive ancestry, is Red Hat. [2]  We totally respect them. But if we tried to do what Red Hat does – well, we aren’t designed to do that.  Just as a nightlight isn’t designed to guide sailors.  More importantly – we have our own strengths. And we embrace those strengths, just as the little blue canary nightlight does.

The rest is easier. “Bluebird of friendliness; like guardian angels, it’s always near /  Blue canary in the outlet by the light switch / who watches over you / Build a little birdhouse in your soul.”   Interpret at your own will, really. It speaks for itself.

I have a home for Fedora in my soul. My Birdhouse is filled with all of the things about Fedora that are near and dear to my heart. And I like to think that I continue to build that little birdhouse in my soul every day, in one way or another.   The Cloud SIG, the Marketing team, FUDCon… these are the things that are important to me.  The things I care about, and want to grow, and flourish, and eventually pass off to others to make even better.

I love Fedora because *anyone* can build a little birdhouse in their soul for Fedora.  It’s versatile, it’s flexible, it offers opportunities for people to build that birdhouse in their soul that you won’t find ANYWHERE ELSE.  And for every individual in Fedora, those things are different, and special.  And makes Fedora, Fedora.

A lot of times, we forget about that birdhouse.   I think that nearly every contributor has a reason *why* they’re passionate about Fedora, why they continue to contribute, what brought them to Fedora in the first place.  The birdhouse can tend to get cluttered with a lot of other crap.  You know what I’m talking about: Things you committed to at some point, but your interests have changed; frustrations about disagreements; getting stuck on a problem you can’t solve.  We get so wrapped up in those things that we forget to keep building that birdhouse – we lose sight of the things we love. And the things we love are really what keep us going.

I challenge you (one american dollar, not included): Think about your birdhouse a bit., maybe over the course of a few days.  Have you looked at it lately? What are the things that you are *passionate* about in Fedora? Have they fallen by the wayside? What can you do to get back to doing those things you love to do?

There really should be no “Might” in my blog post title. It’s really just a play on the band name. We are *all* giants.  We all possess the power to do great things in Fedora.  And even when some of the things we work on as individuals seem as though they’re diverging, or maybe don’t seem like they’re on the same general pathway — it all comes back to what Fedora has always been great at, and the reason why so many of us are here today: Fedora the Product is filled with the tools and materials you need to BUILD THAT BIRDHOUSE IN YOUR SOUL.  And as we individually build those birdhouses, we create more materials, more tools, for others to come and remix, and reuse, and build their own birdhouses.  And, in the end,  enable new contributors to stand on the shoulders of giants[3].

[1] This is the one minor detail that puzzles me, as they actually sent a dove between the rocks, and there wasn’t really a lighthouse involved, but, well, this works, I suppose.

[2] This is not an “upstream/downstream” metaphor; in that case, Fedora is really the ancestry of RHEL. What I’m talking about is more of a historical timeline.

[2] I promise that my next blog post will not be an allegorical interpretation of the song “King of Birds,” by R.E.M.  Even if it does say something about “standing on the shoulders of giants,” and “a hundred million birds fly.”

Live from Utah, it’s Quaaaaaaaaaaaid!

Taking a tip from Ruth Suehle, who liveblogged/transcribed my session on Open Marketing at Ohio LinuxFest recently, I’ll be transcribing Karsten Wade‘s keynote this evening at UTOSC. We’ll see how it goes (my transcribing, since I know Karsten will kick ass.)


Getting ready


Karsten is speaking on “Barn Raising & musicians on the green – old ideas in a digital world.”

Taking a few moments to lay out his bona fides – why he’s here, etc. Appreciates that the UTOSC folks have invited him.  Important part of open transparency to know why he’s here – not just because he’s from a company – he’s been a FOSS advocate for 10 years, starting at VA Linux, then laid off in the scary market days and hired by Red Hat.  He’s worked on professional services team, documentation, wrote the original SELinux guide, helped start the Fedora docs project.  He works on Red Hat’s community leadership team – they get involved in things near and dear to red hat, either to help solve problems or to continue to help grow.

Questions – who’s comfortable with what open source software is? Can you explain what open source is within about 2 minutes? One minute? Thirty seconds? He did 15 seconds at the train station the other day.  He wants to help us understand it better and explain better.

Free <3 Open <3 Free. The basic idea of FOSS is that you have a set of inalienable rights. To study, fix, make modifications, redistribute with modifications, and being able to run software. You need to have all the freedoms you need to be in a freedom situation.  None of us are free until all of us are free.  If there are restrictions, then you’re really not free.

We all agree that freedom is important – some people think it’s #2 vs. #1 in open source, but we all more or less agree.  But he’s not talking just about free software – he’s talking about the Open Source way.  He’s going to take us back a bit and apply these ideas – some of which we’ve done for a really long time – and apply them in other areas.

No surprises overview of the talk:

1. I cover terminology about the open source way.

2. I tell stories and ideas that illustrate the open source way

3. We gain common ground on what the open source way is

4. You tell us illustrative stories & examples.

Know the ingredients of the open source way: An infrastructure of sharing (which requireas an infrastructure of participation) + Something to share (which needs someone to share it: participants.)

Communities of practice. (Karsten reads off the long definition from the book!)

Elements of a Community of Practice: Domain (what), Community (Who), Practice (how).  Just because someone in a community is silent, doesn’t mean they are not participating.

Principles of Communities of Practice:

1. Design for evolution. The community is going to be thinking about current and new ideas for the future.

2. Open a dialogue ‘tween in/out. Make sure that new people aer able to look in, and old people can look out.

3. Invite different levels of participation. Unless someone is actively destroying the community, let them do it. Experts don’t just parachute in from the sky. Legitimate peripheral participation – anywhere in the circle, they can participate.

4. Develop public / private spaces.  Being public is strong for a community, but you can also have private discussion with people – be friends and have private bonding relationships too.

5. Focus on value.  There is an intrinsic value people are looking for. Make sure they can see it.

6. Combine familiarity & excitement. You know what’s going to happen, but sometimes, exciting new things happen.  Have a sense of rhythm – we still have meetings weekly, or we’ll be at the coffeeshop on Wednesdays, etc.

The Tunnel of Excitement

7. Create a rhythm for the community. (Regular meetings, etc.)

Raising a barn (infrastructure of participation).

Foundations have to be laid to do big things.  He was at the train station the other day and someone asked what they were in town for – he said Open Source software is built in the same way that everyone builds a barn.  People get together and lay the foundation and do it.  When people get together to build barns, they do it the same way they build towns – there are common elements that come back again and again. When they do it right, they feel right – when they do it wrong, people don’t want to be there. Putting the right infrastructure in place.  Another common element is the village green.

Musicians on the green (participants sharing).  Musicians are singing together, people are listening, you play something interesting, i lay something interesting, and share elements with each other, and even other people who come from far away. It’s almost like friendly competition and learning from each other – sometimes people are friendly about wanting to take and then improvise on each other’s work.  At Grateful Dead concerts – people can record and reshare songs within the rest of the community. It’s a tireless ecosystem, a lifestyle ecosystem.

Tom Sawyer is not the open source way.  “Say Tom, let me whitewash a little!” Tom is painting and a friend comes along – if he makes the whitewashing look really great, maybe a friend will come help us out.  Within a few minutes, his friend is begging, and then later his friends are there helping, all because they think it’s awesome. That’s how a lot of people think Open Source or Red Hat is – but that’s really not how it works.  It does happen, but the truth is that the community notices things like that.

Tom Sawyer

“Resonance naturally amplifies even the smallest of properly coordinated incremental impulses.” – Michael Tiemann.  He tells the story of his daughter playing with a magnet, and thinking it is broke. He shows her – adds small tugs, one by one, until a huge object is moving back and forth. Rhythm – or every 6 months having a release – just keep on tugging and you can make communities move.

Stories from the audience:

* Neighbors getting together to help each other move.

* Communities solving hard problems – medical research. Communities doing things like raising money to find a cure for cancer.

* The community garden.

Karsten also has a few videos for us to watch!

Some links:

Thanks to quaid for an awesome session.  Hopefully my transcription somewhat resembles what he was trying to get across :D

The Triangle of Fedora User Zen… or perhaps the Bermuda Triangle of Robyn’s Very Tired Mind

So….. I did a lot of thinking this evening on the discussions of the NOT YET SOLIDIFIED OR SET IN STONE User Base Triangle, as discussed earlier this week during a FAB meeting.  Of course, I’m totally wiped out from all the work we plowed through at the Marketing FAD, so who knows if any of this is even coherent.  I think it is – maybe some of my definitions are off, but it’s a start.

Basically – it comes from the User Base work the FAB SWG has been drafting up.  Rather than have these folks as Horizontal Layers of addressable markets – which, it seems, makes a lot of people think that what is defined as the “absolute bare minimum type of user” will actually be the only people we market to (NOT TRUE) – I decided that the Horizontal categories should actually be the Fedora Foundations – Freedom, Friends, Features, First.   And that the User Base people should actually be vertical groups, overlaid onto the Foundations – the higher their understanding / experience of those foundations are, the more likely they are to become serious contributors, over time.  There are 4 user base “buckets” – I added a fifth one to the diagram, Developers (there’s a longer name, actually, but that’s the short version).

  • Features: This is what gets the User Base in the door.
  • Friends: After being in the door, individual Users can become Friends via various paths.  Reaching out to someone tweeting about their experience, good or bad; responding to help requests on forums; commenting on blog posts; for some users, IRC, mailing lists, etc. Getting local users to attend FUDCons.   Reaching out and basically doing one of the many things that the Fedora community excels at already: being a Friend to those new users, starting the dialogue, and helping users not just understand Fedora the Distro, but also Fedora the Community.
  • Freedom: This is where users are aware of how they can contribute to Fedora – whether it’s submitting a bug, being willing to discuss and/or document an experience, working on the wiki to contribute thoughts, coming to a meeting, supporting other Newer Users who are going through what they went through.  They realize that they have the Freedom to change things for the better.  Further along in their path up this horizontal bracket, they start to learn about things like F/LOSS, TOSW, and perhaps even the concepts of how licensing affects them, and how being an open community helps to better the very product they are currently using – and they become participants in that community.
  • First: This level is truly about innovation.  It’s about doing the things that make Fedora the Distro, AND Fedora the Project, a true leader.  This is about empowering contributors who may have been working on helper tasks to embark on bigger projects; getting engineers to do New Things that nobody has done before; anything that is a new way of thinking.  These New Things become Features – and those features head down to the bottom of the triangle, paving the way for a new group of Users to discover Fedora.

This is all about moving people UP the triangle in their understanding of the Foundations – living by the Foundations make Fedora the Community a great place to be, and encourages users to stick around.  Some users, perhaps a portion of some of those on the edges in this diagram, may never do more than be friends, and that’s okay; other users, as they discover Freedom, will move up.

Robyn's User Triangle Draft

Draft goodness, yo... might want to click for larger version for readability's sake

There is quite a bit of redundancy between the diagram and what I’m saying here; but, there is also quite a bit of additional context built into the User Base Triangle draft I wrote.  For all I know, this may not be what the Board has in mind.  But the bottom line is that I think we shouldn’t think that these users are stagnant, and we shouldn’t think ourselves, internally, that we’re only targeting a certain group of people with a certain level of expertise.  That’s not the case at all.  We should be doing everything we can to move people who are reaching out from being Friends to Friends who know what Freedom is – and helping them use that Freedom to do New Things.

Anyway… HOLY CRAP, I’m tired.  Link to my fp.o page with my personal draft is here. I just realized that the “inexperienced computer users” box seems to span the triangle in a way that says, “I’m all of these groups,” and that’s not it at all; it’s more like… those guys are outside the triangle, and unlikely to move UP the triangle in their self-actualization of Fedoraness. I realize this picture is like… completely miniature / miniscule, but a larger version appears on the previously mentioned fp.o wiki page; also, I provided the Inkscape .svg file so that you can take what I’ve done and recraft your own version…. or alternately, you can take it, delete everything and create your VERY OWN! That’s right folks. I’m just -that generous-. So generous, I’ll link you to that .svg directly. (It actually seems, at least for me, that if you click on that link it will still open a picture; I’m not sure if you download it, that it will actually work in the magical ways that I sort of implied. I think it should, though, be able to be downloaded, opened in inkscape, and turned into further goodness. I’m sure someone who actually knows what they’re doing could inform us all of this!)

Speaking of generous: I would love your generous feedback. I love the nice kind, and mostly love the flame kind.  If anyone is thinking I may be on to something here (other than thinking that what I’m on is drugs, and it’s a bad idea, of course!) – I’ll refine this in a few days and throw out version 2.0, which could be new and improved with gradients, better colors, layers that are locked together, fonts that are slightly larger, and words that are more concise.  And if not – Believe Me, I have a little notebook brimming with ideas on all sorts of things, which I’m sure you’d love to read about in yet another one of my fabulous, rambling blog posts.

I may write / modify this blog post tomorrow as I clarify things more. Or as others clarify things for me. I say tomorrow; I mean later today, it’s 2am.  I’m completely wiped from the awesomeness that was Marketing FAD (thumbs up!) and the flight home yesterday from RDU to PHX next to the lady who barfed TWICE and also was a total space invader with her elbows crossing my personal space area… over the armrest… into my ribs (thumbs down!).

On a different note: I went from Inkscape Noob to Okay Inkscape Novice in a few hours this evening. Not bad! (Note to self: instead of spending 30 minutes trying to figure out how to do $simpletask, several times, CONSULT MANUAL ONLINE. Seriously. It’s all in there, Robyn.)

National Broadband Plan – A Hilarious but Sad example of TOSW Fail

I saw a tweet this morning from @CatoInstitute that led me to one of the most hilarious (or, well, pathetic) things I’ve ever seen.  Well, hilarious in the way that it is yet another prime example of government bureaucracy fail  Obviously, someone at the FCC got a task list and decided to plow through it without even considering if maybe, MAYBE, since a transparency is a GOAL, they should do this work transparently. Just to summarize so you know what I’m rambling about, the FCC has decided to execute some sort of “National Broadband Plan,” and now some of that work has been published.

I can’t possibly say it better than the author did in the article. I’ll just paste the link, and the quote from the article which stood out at me:

In a highly symbolic gesture, the Federal Communications Commission published the executive summary of its “National Broadband Plan” in one of the most opaque formats going: It’s a PDF scan of a printed document.

This means you can’t cut and paste the bullet point that says:

“Increase civic engagement by making government more open and transparent, creating a robust public media ecosystem and modernizing the democratic process.”

Can an agency that publishes documents in inaccessible formats be relied on to deliver transparency?

Exactly.  EXACTLY.  Can someone please go hit the FCC on the head with a link to so they can start learning about the Open Source Way?

Thank you, drive through.