As we we think about what “change” means to the future of the Fedora Project, I couldn’t help but think of it in light of Seth Godin’s post, The Reason You are Stuck:

The resistance loves committees and it hates a mission. The resistance creates fear and uncertainty, and it will do almost anything to keep you from being noticed.

And so the resistance kicks in. The resistance goes to meetings and plays devil’s advocate (I didn’t know the devil needed an advocate.)

The resistance finds excuses, it makes tasks needlessly complex (or oversimplifies so much that you fail). The resistance uses phrases like, “see, I told you it would never work.” The resistance demands that you study the issue more, or grab a Diet Coke, or go visit those friends who are in from out of town and you won’t be able to see them unless you go right now. The resistance invented yak shaving. The resistance is also responsible for giving you an even better idea just before you finish this one… in fact, the resistance will do anything it can to prevent you from shipping.

Unfortunately, the web is filled with tips and tricks and lists that appear to help you in your quest to shut up the lizard, to defeat the resistance. I say unfortunately because these lists are calm, practical and ultimately ineffective. They are polite in the face of a nefarious enemy, they are rational in the face of screaming insecurity. None of them are working for you because you may not be serious about actually defeating the resistance. It’s fun to procrastinate and comforting to dissemble, because not shipping doesn’t arouse the lizard brain. It’s safe.

Here I equate “not shipping” with not taking action or pursuing change–more talk and ideating–arguing on mailing lists, and the status quo.  Anyone that knows me a little bit knows that it is rare for me to make a rash decision or to take a big leap without thinking about it first–sometimes too long.

Something you might not know about me or maybe you’re starting to pick up on, is that I’m tired of playing it safe.  I’m actively working on ways to get me and Fedora out of our comfort zones.  The result could be failure, but that is not all bad.  Karsten had a good post on failing often.  The January 2010 issue of Wired had a cover story dedicated to the benefits of “Fail.”

Great things usually happen by taking risks, not by playing it safe.  It seems like one of the biggest obstacles to embarking on change is the fear that the new ideas will be the wrong.  Worse, that those wrong ideas will cause damage.  And ultimately, that the damage will be lasting.

To which I say, “How likely is that, really?”  Is the risk of changing or trying something new in Fedora really that big?  What if we tried a new updates policy and it failed and we had to try something else?  Why does it have to be perfect the first time?  Couldn’t we learn from the failure too?

If we do something wrong and we are smart about it, we’ll learn from it and make it right.  I find it hard to believe that the Fedora Board could propose a new direction for Fedora that would fail so miserably it would permanently kill everything folks have worked so hard to build or that a restricted updates policy would damage the Fedora distribution forever.

I guess I’m at the point where I’d rather spend some time recovering from a fall because we tried to climb a daunting pitch instead of sitting on the ground talking about how dangerous it might be to try.  I doubt any of the world’s most innovative ideas or products were created perfectly the first time.

I am happy to report that the Strategic Working Group has made a lot of progress since it started meeting in January 2010.  Every week we’ve mowed down at least one issue and soon we’re about to attack one of the big issues that started it all.

One of the most interesting discoveries as the Strategic Working Group has moved forward is that in many cases we aren’t recommending changing anything.  In many cases we’ve simply enhanced our existing project documentation to explain the current environment and past decisions better.