This is a read only archive of pad.okfn.org. See the shutdown announcement for details.

writethedocs-new-community New Community 

walkthrough.it - Trying to bootstrap a community
- going prety well with guerilla marketing, events

Has anyone bootsteapped the comminty? how did you do it?

Structuring the community
- would like a decentralized, distributed community,
  - like Drupal - huge, lots of leadership, but decentralized
    - maybe because there's a lot of "leadership vacuum" at the top
    - lots of bi egos could grow & take over
  - why do we want it that way?
    - pros
      - ambition:
          - want it to be really huge
          - want an open standard that the whole wrld will be using
      - a good project to work in
      - open source => more momentum 
        - not really an argument for decentralizing the community
    - cons
      - companies might be afraid if it's decentralized
      - someone needs to define the standards
        - purely volunteer-based community is bad for standardization
          - missing power structure
    - Wordpress community vs. Drupal community
      - Drupal
        -  gift-based culture
        - many small Drupal-based companies
      - Wordpress
        - I make a plugin, you pay me for the plugin
        - freelancers
          - is this because they do less complex work?
- is if possible when starting as a company?

What's the point? What do we want to do?
- Why do people want to contribute?
  - Drupal, Mozilla - modular, people can take ownership of their work
    - technical communities - almost always an aspect of ownership
    - "prime directive"
      - Drupal: other CMSs suck, we're building a better one
      - Mozilla: lots of different motivations
        - when they started, it was: people hated Misrosoft
          - pretty powerful
- Q: What's your "prime directive"? Why would you care?
  - "how to do it" follows from that
- People loving the product + open sourcing it
  -> people are happy to contribute
- A crazy idea:
  - you could get money to bootstrap the community, or
  - make it a coop - customers/employees/suppliers "own" the service
    - lots of investors that all pay a bit of money, but become owners
      - advantage: financially involve the users
        - another incentive to work on iy
        - or a hurdle - getting involver in a coop (possibly internationally) it difficult
        - you first need to get the users
      - is this even relevant to our discussion?
- How did Elasticsearch get so big?
  - 100% centralized
    - 1 company employs all core contributors
      - lots of 
  - started by 1 guy
    - few people used it and loved it
    - technical - it worked, solved a difficult problem
    - support - author on IRC 24h a day
    - the *spirit* in an open source project goes top to bottom
     - owner(s) enthusiastic -> everyone who joins is enthusiastic
       - same in Django
  - many contributors just want to see their name in there
    - have resources to help others join the project
    - needs long term investment into helping others get on board
      - elasticsearch: core developers who knew "everything" stalled development,
        - concentrated on helping others
        - after a time this sped up development substantially
  - make the project internals amazing, so people want to work on it
- walkthrough.it: gearing toward both documentarians and developers
  - how to gear it? top-to-bottom, or bottom-up?
    - Elasticsearch: banks - bottom-up:
      - don't sell to the bank
      - get developers to run it
      - decision time comes along - developers recomment what they know
      - MySQL used the same strategy
        - a warning example
          - developers work for a company with a competing product
  - another problem: a company works on it, why should I?
Ownership
  - drupal & Mozilla have distributed ownership
    - people are paid, but they keep ownership
      - lots of incentive
    - also what we want is lots of small contributions
      - ownership doesn't come into play here
      - libraries vs. products
        - Firefox - most users can't fix bugs
        - Django - every user has the skills to fix Django
      - lower bar to contribute
        - much more open, diverse community
        - you can take as much or as little responsibility as you want
          - tone & messaging - people need to understand where the bar to contribution is
          - formalization of the steps: this is how you contribute, this is how you run tests
          - make it easy for contributors to explore the project
            - MDN: lead people from fixing easy tasks to becoming a module owner
            - apprenticeship, mentors, handholding help a lot
              - sprints at a conference - same effect, less resources
              - contributors see that getting started is not hard
              - offering opportunities
              - different opportunities for different skillsets
              - bug tracker - mark bugs as "easy fix"
                - openhatch - aggregator for easy bugs across projects
            - the second step is also important - how to retain contributors?

=== Session 2 ===

How do you maintain a healthy community

- So far we talked about contributors. Do we want to include users?
  - MDN - had a big discussion on this
    - there are contributors who don't participate in the community
    - there are community members that don't "contribute"
     - e.g. evangelists
    - we value other things than just contributions
  - conferences - organizers & attendees - what are they part of?
  - organizing stuff as a way to get visibility in the community
    - takes a lot of time to get as appreciated as the developers :(
      - the "inner circle" didn't really notice newcomers
    - Drupal: permissivenes
      - you can just organize a meetup, don't have to ask for permission
        - this started up a few communities
        - this ties back to ownership
          - support structure
            - we'll supply speakers, know-how, money, but it's still *your* meetup
  - Cathedral & Bazaar - both can be there
    - some just want to contribute
    - some have a plan, want to contribute to ahigher goal
    - it's a scale, a project can have more of one or the other
    - open question: How important is the "personal touch": to grow a community?
      - evangelists, meetup, events
      - it's about humans, interactions, individuals
        - trust - you're more cautious with contributions from new people
        - at events, you can build relationships
         - this is why the conference hallway track is important
      - Jannis: the personal touch is a requirement
        - seting the tone is a part of this
      - MDN: 3 distinct "hats"
        - people who just do stuff, but don't talk to others
        - people participating because of the people
        - people that want to get involved in the community, looking for a niche for themselves
      - Elasticsearch: when we go do a training, we also organize a meetup
        - people see there are real people behind the project
      - Drupal: Come for the software, stay for the community
        - newcomers feel welcomed
        - need people actively looking out for newcomers
      - there can be bad blood in the community, especially with volunteers

Is churn inevitable? What'ds the life span of community involvement?
- MDN: university students
  - people contribute for a couple of years, then get a job, and eventually leave
  - seems to be universal
  - people do translations to learn the project
  - what to do with people with burnout syndrome?
    - at that point it's too late
    - "going through" release managers fast
    - general questions:
      - how to prevent people from burning out?
      - how to keep people engaged & happy?
      - how to gauge that?
    - structure
      - can have personal relationships with people in your group
    - only care about the heavy hitters
      - can track these, can talk to these
      - no substitution for actual contact
    - ES: a message from the creator is all that's needed for an unhappy person
      - personal follow-ups are nice (a card from Mozilla)
    - community managers?
      - how to be a good community manager
        - talk to people?
        - understand how to solve problems for a community?
          - connect people that work on the same problem
        - connection building
        - knowing what everyone does, to connect them
          - find poeople with similar interests, throw a beer at them
        - ES: most people need to engage the community
          - evangelizing is part of the job description
          - Mozilla is the same: all employees are representatives
              - awareness of how people can contribute
          - walkthrough.it
            - can only send one person to conferences
          - Mozilla: effort underway to make sure people are "socialized"
            - hire people to do boring stuff
            - community should do cool stuff
            - doesn't scale - community contributor won't write a big feature
          - ES: a technical guy with bad social skills
            - is it better to close (not open-source) that portion of the project?
            - most companies are not open-source
              - even here, opennes is important for the open project
                - otherwise you lose the welcoming aspect