Wednesday, June 2, 2010

Open Source Bridge - Being a Catalyst in Communities - The scientific facts about the open source way

Karsten Wade, Sr. Community Gardener, Red Hat
  • @quaid
  • FOSS advocate for 10 years
  • being a catalyst in communities
    • to be the catalyst in communities of customers, contributors, and partners creating better technology the open source way
      • word "in" is important
      • "in" could have been "over," or "of," or "for" ... but none of these work as well because it creates an imbalance
      • "in" suggests everyone being in it together
    • currently have a doctoral candidate in cultural anthropology at Fedora who's helping the project get better
      • learn about Fedora, learn how they do things
  • a lot of people think open source works the same way tom sawyer got his fence whitewashed
    • tom sawyer would rather go down to the swimming hole
    • friends come along, so tom acts like he LOVE painting the fence and his friends start painting the fence for him
  • model actually works a lot differently -- barn raising analogy is better
    • need to do a lot of work before you call people in to do the actual barn raising
      • build the foundation, do the preliminary work
      • doing the actually raising is a great thing to have the community do
    • can't call everyone in too early or too late
  • example of interaction in red hat community - http://lwn.net/Articles/83360
    • written by someone inside red hat projects to show what it looks like to the outside world
    • story of how fedora came about
    • early days of red hat, developer side was coming along pretty well
    • customers and people writing software for RH had issues with the speed at which new distributions came about
    • now, fedora is released every six months, and RHEL is a snapshot every 18 months with longer-term support
      • this model works well for businesses but didn't work as well for the community overall
    • always a challenge to strike a balance when a company needs to keep some information private but the project is open source
  • around fedora 2 timeframe the NSA contacted red hat to talk about a security-enhanced version of linux
    • trying to get out of vendor lockin with another vendor
      • took base OS and slapped security stuff on top, but couldn't upgrade, support, etc.
      • NSA understood the open source model and thought it would address their issues better
    • fedora core 2 added SELinux
      • gotten better over the years, was kind of rough early on
      • people turned it off originally--it's on by default and that irritated a lot of people
      • it's ok to disappoint people in OSS, but it's never OK to surprise people--you'll lose them and they won't come back
  • fedora 7
    • dropped the word "core" from the name
    • prior to fedora 7, all the build tools were behind red hat's firewall
    • in the meantime the community created a build process that was better than red hat's
    • fedora 7 and forward enabled anyone to do builds
  • virtualization
    • RHEL 5 timeframe, xen was the only technology really available at the time
    • xen is code outside the kernel so this made including it in RH more difficult
    • at the same time, kvm was being done and it was in the kernel, which made things more easy to integrate
    • libvirt abstracted the actual VM technology under the hood
      • this kind of went against the direction of the community but red hat gave a clear roadmap as to why they were doing what they were doing
    • red hat wound up buying the company that was working on kvm
  • POSSE - Professors' Open Source Summer Experience
    • week-long bootcamp to help teachers teach open source
    • people graduating don't have good experience with real-world projects by the time they graduate
    • red hat went to people who taught open source to learn about the challenges
      • wasn't a single location for educators to discuss teaching participation in open source
      • academic calendar very different from the open source calendar
      • success formula -- if educator is involved in an open source project and knows how to participate, they're much more likely to encourage their students
    • even with the projects, helps to teach students how best to interact with open source projects
    • have some real-world marketing classes to each people how to market open source projects
    • created http://teachingopensource.org
    • text book - Practical Open Source Software Explorations
    • first POSSE held in Raleigh in 2009
      • worked on mozilla, packaging, dealing with bugs, etc.
      • nothing too technically difficult but getting a feel for the process and how to get involved
    • cultural differences
      • did a POSSE in China and while in the US we're OK with more collective learning, professor not necessarily being an expert, etc. but it's different in China
    • idea of "productively lost"
    • contributing
      • e.g. wiki translations and contributions -- showing people how they can make a difference
  • communities of practice
    • "communities of practice are formed by people who engage in a process of collective learning in a shared domain of human endeavor: a tribe learning to survive, a band of artists seeking new forms of expression ... in a nutshell: communities of practice are groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly." Wenger, McDermott, Snyder - "Cultivating Communities of Practice"
    • entire body of social science work around how communities work
    • about more than number of users in the system or number of downloads
    • more about the overall health of the community
  • elements of a communities of practice
    • domain (what)
    • community (who)
      • the people who care about the domain of knowledge
      • need to allow people to be themselves and not try to force them to be who you want them to be
      • only reason to shut someone down is if they're actively doing something poisonous
    • practice (how)
      • turn knowledge into something that can be spread around
  • principles of communities of practice
    • design for evolution
    • open a dialogue between inside and outside people
      • people on the inside need to maintain openness and transparency
      • people on the outside need to feel they're being heard, and also know how they'd become one of the inside people
    • invite different levels of participation
      • every aspect is important
      • experts don't fall out of the sky, more likely they'll be created from within
    • develop public/private spaces
    • focus on value
    • combine familiarity & excitement
    • create a rhythm for the community
      • weekly meetings, release every six months, etc. -- create expectations
  • free <3 open <3 free
    • bottom line is that free software is a great brand that works for hackers, open source is a great brand that works for businesses
    • not trying to say one brand is better than the other
  • Book: The Open Source Way: Creating and Nurturing Communities of Contributors
  • http://quaid.fedorapeople.org/presentations

No comments: