7 Open Source lessons from your English Composition class

We often act as if coding, and especially open source coding, is a unique activity and that’s hubris.   Most human activities follow common social patterns that should inform how we organize open source projects.  For example, research papers are very social and community connected activities.  Especially when published, written compositions are highly interconnected activities.  Even the most basic writing builds off other people’s work with due credit and tries create something worth being used by later authors.

Here are seven principles to good writing that translate directly to good open source development:

  1. Research before writing – take some time to understand the background and goals of the project otherwise you re-invent or draw bad conclusions.
  2. Give credit where due – your work has more credibility when you acknowledge and cross-reference the work you are building on. It also shows readers that you are not re-inventing.
  3. Follow the top authors – many topics have widely known authors who act as “super nodes” in the relationship graph. Recognizing these people will help guide your work, leads to better research and builds community.
  4. Find proof readers – All writers need someone with perspective to review their work before it’s finished. Since we all need reviewers, we all also need to do reviews.
  5. Rework to get clarity – Simplicity and clarity take extra effort but they pay huge dividends for your audience.
  6. Don’t surprise your reader – Readers expect patterns and are distracted when you don’t follow them.
  7. Socialize your ideas – the purpose of writing/code is to make ideas durable. If it’s worth writing then it’s worth sharing.  Your artifact does not announce itself – you need to invest time in explaining it to people and making it accessible.

Thanks to Sean Roberts (a Hidden Influences collaborator) for his contributions to this post.  At OSCON, Sean Roberts said “companies should count open source as research [and development investment]” and I thought he’s said “…as research [papers].”  The misunderstanding was quickly resolved and we were happy to discover that both interpretations were useful.

Back of the Napkin to Presentation in 30 seconds

I wanted to share a handy new process for creating presentations that I’ve been using lately that involves using cocktail napkins, smart phones and Google presentations.

Here’s the Process:

  1. sketch an idea out with my colleagues on a napkin, whiteboard or notebook during our discussion.
  2. snap a picture and upload it to my Google drive from my phone,
  3. import the picture into my presentation using my phone,
  4. tell my team that I’ve updated the presentation using Slack on my phone.

Clearly, this is not a finished presentation; however, it does serve to quickly capture critical content from a discussion without disrupting the flow of ideas.  It also alerts everyone that we’re adding content and helps frame what that content will be as we polish it.  When we immediately position the napkin into a deck, it creates clear action items and reference points for the team.

While blindingly simple, having a quick feedback loop and visual placeholders translates into improved team communication.

Just for fun, putting themes to OpenStack Conferences

I’ve been to every OpenStack summit and, in retrospect, each one has a different theme.  I see these as community themes beyond the releases train that cover how the OpenStack ecosystem has changed.

The themes are, of course, highly subjective and intented to spark reflection and discussion.

City Release Theme My Commentary
ATL Ice House Its my sandbox! The new marketplace is great and there are also a lot of vendors who want to differentiate their offering and are not sure where to play.
HK Havana Project land grab It felt like a PTL gold rush as lots of new projects where tossed into the ecosystem mix.  I’m wary of perceived “anointed” projects that define “the way” to do things.
PDX Grizzly Shiny new things We went from having a defined core set of projects to a much richer and varied platforms, environments and solutions.
SD Folsom Breaking up is hard to do Nova began to fragment (cinder & quantum neutron)
SF Essex New kids are here Move over Rackspace.  Lots of new operating systems, providers, consulting and hosting companies participating.  Stackalytics makes it into a real commit race.
BOS Diablo Race to be the first Everyone was trying to show that OpenStack could be used for real work.  Lots of startups launched.
SJC Cactus Oh, you like us! We need some process This is real so everyone was exporing OpenStack.  We clearly needed to figure out how to work together.  This is where we migrated to git.
SA Bexar We’re going to take over the world We handed out rose-colored classes that mostly turned out pretty accurate; however. many some top names from that time are not in the community now (Citrix, NASA, Accenture, and others).
ATX Austin We choose “none of the above” There was a building sense of potential energy while companies figured out that 1) there was a gap and 2) they wanted to fill it together.

Parable of Kitten Taming

It’s time to return to story of Barney and Bailum.  Last year, I wrote about their separate paths through the circus business: Bailum succeeding with a lean model and Barney failing with a “go big” strategy.  This parable opens with Bailum taking pity on Barney and bringing him into her thriving animal training business.

Bailum had grown her Lion taming business from the ground up.  She started from humble beginnings with untrained dogs; consequently, she’d learned about building rapport and trust with her performers.  She never considered them to be animals.  To her, everyone in her organization (especially the animals) was a valued contributor.  She’d seen first-hand that just one bad link in the chain could cause a great performance team to turn sour.  Her acts won awards and she was proud to have them in the spotlight while she focused on building trust and a sustainable culture.

Unfortunately, Barney did not share his sister’s experience or values.  He only saw the name that she’d built for the company and felt that he could use his position and relationship to promote himself.   Even though he knew nothing of animal training, he was eager to redirect his staff into new areas.  Reading market data and without consulting his trainers, he decided that a cute kitten acts would attract more business than the company’s successful dogs acts.

Overnight, he released the dogs and acquired kittens from a local shelter.  Some of his trainers simply quit while others made an attempt to follow the new direction.  Barney was impatient for success and started watching the trainers learning to work with the frisky felines.  Progress was slow and Barney vented his frustration by yelling at the trainers and ultimately putting shock collars on the kittens.  In short order, the trainers had left and Barney was being sprayed, scratched and bitten by the cats.

When Bailum learned about her brother’s management approach she was mortified; unfortunately, he had also signed contracts promising kitten acts to their customers.   After restructuring her familial entanglements, she took a personal interest in training the kittens.  She immediately recognized that cats require independence instead of direction compared to dogs.  Starting from careful handling, then bringing in her lion tamers and rewarding positive results, she created working troop.  The final results were so effective (and logistics so much easier) that Bailum ultimately transformed her business to focus on them exclusively.

Moral: you can’t force cats to bark but, with the right approach, kittens can outperform lions

DevOps for Non-Profits?! The Miracle Foundation does IRL Puppies v. Cattle

In what’s become an annual tradition, I’m taking a post to think about the intersection of Cloud and Non-profits using my better-half’s employer, The Miracle Foundation, as my inspiration (and to help support their Mothers’ Day campaign).

TMF girl with puppyTheir deceptively simple sounding mission is to nurture children – they’ve just added some minor wrinkles like the children are orphans, in economically challenged areas generally tucked away in remote areas of India half way around the world from their Austin HQ.  That does nothing to dampen their tenacious drive to ensure that these children have the benefits of food, health care, housing, education and, most critically, nurturing caregivers.

How does that relate to the Puppies & Cattle analogy?

Like any scalable operation, they need to create highly repeatable processes to deliver their service.    The Miracle Foundation service, environments where house mothers nurture children, is by its very nature a “puppy” since each child must be treated uniquely; however, everything leading up to the point of delivery must be “cattle-like” to they can scale the care they give.  For example, unique lesson plan is good while a unique chart of accounts is not.

Last year, I talked about how the Miracle Foundation was using quantitative measures to evaluate quality of care.  They’ve used these metrics very effectively in their operations to identify places where they must standardize (like accounting practices, health care regimens and dietary requirements) and high touch places where they cannot (selecting and promoting homes out of incubation).  Exactly like cloud deployments, success means finding places where variation creates complexity (cattle) and ones where it increases value (puppies).

I’ve been impressed to see how the Miracle Foundation identified the need for standardized house-mother training curriculum as part of this analysis.  Their years of experience across a breath of orphanages has shown that giving clear guidance and setting standards for the people in direct contact with the children nets tremendous results; however, just making sure this training is delivered means building up a lot of other process and standardization.

If you think your job of building DevOps scripts and practice is hard then you need to step away from the keyboard for a while.  This organization, and other non-profits like it, are taking on similar challenges with real people across distances that are more than just a few router hops from your desktop.  I’m inspired by how they take on these challenges and fascinated at how much commonality there is between my work and theirs.

If you’re interested in their mission, please visit them for more details.

Why I’m learning open source best practice from Middle School Students

Engineering in open source projects is a different skillset than most of us have ever been trained for; happily, there is a rising cohort of engineers and scientists who have been learning to work in exactly the ways that industry is now demanding.   Here’s the background…

hedge_teamI’ve been helping mentor two FIRST Robotics teams (FLL & FTC) this season and had the privilege to accompany the FLL team (which includes my daughter) to the FIRST World Festival where a global mix of students from 6 to 18 competed, collaborated and celebrated for a wide range of awards and recognition.  The experience is humbling – these students are taking on challenges (for fun) that would scare off most adults.

While I could go on and on about my experience and the FIRST mission, I’d rather share some of what my 12 year old daughter wrote to her coach after the competition:

Thank you Coach for all of the lessons and advice you have shared with me this season. I really appreciate all of the time and effort you have put into making this team the best we could be. You have taught us so much and we will definitely walk away from this season with the new skills and experiences. You were an amazing coach and not only did you help and support us, you also gave us the freedom to be independent so we can learn skills like leadership, time management and meeting with busy schedules. I loved being on this team and I hope this will not be the last of the Hedgehogs.

FIRST designs the program so that these experiences are the norm, not the exception.

Here are some of the critical open source engineering skills I observed first hand at all levels of the competition.

  • Collaboration: at all levels, participants are strongly rewarded for collaborating, mentoring and working together.   Team simply cannot advance without mastering this skill.
  • Consensus: judges actively test and watch for consensus behavior.  This is actively coached and encouraged because the teams quickly learn to appreciate a diversity of strengths.
  • Risk Taking with Delivery: the very nature of competition encourages teams to think big and balance risk with delivery.
  • Celebration: this has to be experienced but the competitions are often compared to rock concerts.  Everyone is involved and every aspect is celebrated.   FIRST is a culture.
  • Situational Judgment: this competition is fast and intense so participants learn to think on their feet.  This type of experience is amazingly valuable and hard to get in class room settings.

In my experience, everyone in open source needs more practice and experience DOING open source work.  I suggest getting involved in these programs as a mentor, judge or volunteer because it’s the most effective hands-on open source training I can imagine.

Doing is Doing – my 10 open source principles

2013-07-14_17-28-21_468Open source projects’ greatest asset is their culture and FOSS practitioners need to deliberately build and expand it. To me, culture is not soft or vague.  Culture is something specific and actionable that we need to define and hold people accountable for.

I have simple principles that guide me in working in open source.   At their root, they are all simply “focus on the shared work.”

I usually sum them up as “Doing is Doing.”  While that’s an excellent test to see if you’re making the right choices, I suspect many will not find that tautology sufficiently actionable.

The 10 principles I try to model in open source leadership:

  1. Leadership includes service: connecting, education, documentation and testing
  2. Promotion is a two-edged sword – leaders needs to take extra steps to limit self-promotion or we miss hearing the community voice.
  3. Collaboration must be modeled by the leaders with other leaders.
  4. Vision must be articulated, but shared in a way that leaves room for new ideas and tactical changes.
  5. Announcements should be based on available capability not intention. In open source, there is less need for promises and forward-looking statements because your actions are transparent.
  6. Activity (starting from code and beyond) should be visible (Github = social coding) – it’s the essence of collaboration.
  7. Testing is essential because it allows other people to join with reduced risk.
  8. Docs are essential because it reduces friction for users to adopt.
  9. Upstreaming (unlike Forking) is a team sport so be prepared for some give-and-take.
  10. It’s not just about code, open source is about solving shared problems together.  When we focus on the shared goals (“the doing”) then the collaboration comes naturally.

Update a pull request from git command line

Hand up

Sometimes we just need to feed the SEO gods… in this case, I could not find the simple git command line to update a pull request that I had in flight.

I was looking for the following:

git push -f personal HEAD:[pull branch]

Github.com happily gave me instructions from the pull branch but not the CLI version of the command.  The trick is that you need to know your remote (git remote) for the command so it’s not perfectly generic.  In the example above, my personal repo is named “personal”.

Deconstructing the command: you are pushing your to your personal clone from the local HEAD commit against the branch created for the pull request.  That’s because the pull request creates a branch from your clone to be pulled into the upstream repo.  That’s why it’s a PULL request not a push.

Ultimately, this is pretty basic git.  My experience with git is that the definition of “pretty basic” is a binary function.  Once you know how git works, everything in git is pretty basic.  Until then it’s completely opaque.

Side note: this is my 301st post on this blog!

8/1/2013 Post Script from Crowbar Contributor Adam Spiers

He noticed that I should include the -f in the git push instruction.  Read more at about that on his blog.

my lean & open source reading list – recommendations welcome!

Cube Seat

I think it’s worth pulling together a list of essential books that I think should be required reading for people on Lean & open source teams (like mine):

  • Basis for the team values that we practice: The Five Dysfunctions of a Team: A Leadership Fable Patrick Lencioni (amazon)
  • This is a foundational classic for team building:  Peopleware: Productive Projects and Teams (Second Edition) Tom DeMarco (amazon)
  • This novel is good primer for lean and devops The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win Gene Kim and George Spafford & Kevin Behr (amazon)
  • Business Focus on Lean: The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses Eric Ries (amazon)
  • Foundational (and easy) reading about Lean: The Goal: A Process of Ongoing Improvement Eliyahu M. Goldratt (amazon)
  • One of my favorites on Lean / Agile: Implementing Lean Software Development: From Concept to Cash Mary Poppendieck (amazon)
  • Should be required reading for open source (as close to “Open Source for Dummies as you can get): The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary Eric S. Raymond (amazon)
  • Culture Change Liquid Leadership: From Woodstock to Wikipedia–Multigenerational Management Ideas That Are Changing the Way We Run Things Brad Szollose (amazon)
  • More Team Building – this one is INTERACTIVE! http://www.strengthsfinder.com/home.aspx

There are some notable additions, but I think this is enough for now.  I’m always looking for recommendations!  Please post your favorites in the comments!

Parable of Lions and Elephants

ElephantThere was once a family with two children: Barney and Bailum.  Both wanted wanted to start a circus and did exactly that when they came into their inheritance.  Being highly competitive, they each wanted to have the greatest show the world has ever seen.

Always ambitious, Barney wanted to start big and decided to start with elephants.  To have an elephant act, Barney has a lot of planning to do.  Even before acquiring the actual elephants, he had to get permits, hire handlers, arrange transport and arrange special feeding.  He really had to get busy and make some plans even before he could start on the tusks of selling tickets.

Bailum, more humble, decided to start by training some stray dogs into an animal act.  While not nearly as exciting as elephants, she was able to procure dogs immediately and start training them.  Instead of having to host her own shows, she was able to bring the dogs into other people’s shows.  That let her gain critical experience, get a reputation and even have positive cash flow.

Barney was merciless about Bailum’s flea bag circus.  Barney was 100% confident that his vision of a grand circus was the right plan because that’s what he saw from going to other shows.  Based on her behind the scenes experience, Bailum was starting to learn that running a circus was a lot more than the animal shows.  Some of those tasks, like booking venues, selling ads and clown discipline, made cleaning up after elephants look like a circus highlight.

As time went on, Bailum extended her expertise with dogs into lions, horses and even bipedal simians.  Her business was thriving as a specialist for other circuses to such an extent that she abandoned adjusted her original ringmaster vision and embraced a new plan as an animal specialist.  Based on her discussions with her circus partners, her limited scope as a lion trainer was more profitable than their lives in the spotlight.

Meanwhile, Barney was still working out the issues with his elephants.  It seemed like every time he turned around there was a new complication.  After spending every penny on getting his glorious African pachyderms he discovered that his cages were sized for Indian elephants (which are smaller).  Out of money and unable to operate, Barney had to abandon his vision and go back to clown school.

It’s hard to eat an elephant, but if you start with something you can handle then you can learn to tame lions.