CFC INSIGHTS: Community
After the Community call I had a couple of thoughts. Most of my experience is with building community around highly technical topics like open source software and identity, so YMMV. These aren't structured or organized (I am buried this week). Hope this helps.
Community:
Community: it is a process, a practice and everyone's job (where I work)
When it is siloed, when it is trapped in marketing or only in product or only interns, it does not go well
Opinion: community can be a book club where 10 people get together once a month to discuss a book, or a kung fu class that meets 2x a week or an open source project with 10k contributors (firefox).
Each is different, each serves a different need, none of those examples is more valuable than the others.
What matters is the impact it has on the participants, which drives growth or makes it sustainable
Fact: community is a critical need for open source projects which are dependent on code contributions, bug reports, participation
When looking at a project, developers evaluate how many contributors are involved in a project, how many people show up for webinars and conference calls, how many individuals comment and report bugs, etc.
For-profit corporations look at the same things when deciding whether or not to use open source software.
"If we use this, will it be supported?"
From this a lot of those companies have employees work on the open source project as part of their job
Fact: every public blockchain project out there requires community to make it work.
Everyone one of these projects wants developer trial, use and contribution
Every ICO/Token sale is evaluated on the size of the community developing the software, contributing to the project, etc.
Not just to have the community buy the token but as a signal to the market that our ideas are serious, have merit and are going to be something big
Two challenges to community: distrust and competition
Distrust: there are a number of examples of "open source washing" out there
Where a company will open source some or all of its code for the purposes of getting free work or changing perception of bad behavior
The universe of contributors are very suspicious and expecting to be disappointed
They look for any signs of this constantly (before they participate and even while they participate)
"You have sold out" was something we heard a lot at Mozilla
Governance is critical (see the Ethereum community)
"A fanboy knows a hater" - Ready Player One
Competition: there are a ton of projects out there that an individual can participate in.
Want to work on the Linux kernel, start here.
Firefox? Apache? Ethereum? Etc.
How about an open source project building bridges between smartphones and blood glucose meters
Where you spend your time is important, there are too many choices.
Attracting and keeping a community is critical and requires a lot of work
Community in general requires transparency, communication, patience and a lot of work
Transparency:
No secrets, no cabals, no skulduggery.
Community expects decisions to be made in the open, where they can weigh in.
Everyone loves surprises except when they have been contributing their sweat and time.
Communication:
No one wants dictates from on high.
Communication where the community can interact, debate, argue, complain (so much complaining) and just feel like they were heard
Patience:
See comment about complaining above.
As community builders we need to be patient to attract folks to just join.
Patient in explaining how things work and where they can find documentation and code samples, etc.
Patient in being asked and answering noob questions even though we have an FAQ.
Patience in dealing with community members who are jerks even though they are talented, prolific contributors.
Patience for people who want to just use the software and "don't care about your stupid <insert political or geographic ad hominem> values!"
USING our stuff, more open source software in the wild, more examples of people using our code, more feedback from production users is a good thing
We need to pay attention to less-than-nice folks, but we go the extra mile for the others
Patience for those who are only in it for the values, not the code
Work:
This is hard.
We are dealing with humans who have different needs, goals and agendas.
We want to delight them, create open spaces where they can play with/contribute/collaborate with our stuff. Make things we didn't expect. Connect with others like minds, etc.
Community is the hardest work in the world, the most annoying thing in the world, and the most rewarding thing in the world.
Everyone has an opinion on your code or work or ideas - even how you run your community.
Everyone can point to another project that did it differently (or the same) and succeeded
Everyone can point to another project that did it the same (or differently) and failed
You have to listen to all of them or you will miss the right feedback.
More importantly, the wrong ones might be pointing out a different more pressing issue.
If they complain that you don't have a code sample for X, you might dismiss them because you do have one - missing the fact that the code samples aren't easily found or communicated about.
With code-based communities you need to have people, a trailhead, step-by-steps and findable resources
People
People who can welcome, engage and help
People who might have similar needs or something to learn from
Individuals who are "like me" - you want the recognition heuristic to kick in
"Trailhead" in the hiking sense of the word - the starting point.
It can be a document describing how a software works or a curriculum for a judo class.
You start here, the water fountain is there, there is a rest stop here, etc.
Most importantly, it helps community members orient and find their next steps.
Step by Steps
The best developers in the world hate to have to ask the question "so I installed it, what do I do next?", because "whatever you want to do" is not a good answer.
A->B->C isn't helpful, it is required
You want to lead them to the promised land, not off a cliff of "meh"
For a book club it could be "Every month someone else leads the discussion, your turn is in June"
Knowing that there is a technique that builds on the one you are learning now, knowing there is a greater context for the technique helps in a lot of martial arts (the goal is to give you a toolbox of techniques, learned in patterns or forms - at the end of the day you need to learn your scales before you can play improvisational jazz)
Findable Resources
The effort put into the documentation is noticed. Always.
For a book club or Coburn Community maybe not (but I love getting the Coburn blog post emails - so maybe yes)
You are done with community...
Never
Success can be measured but it isn't a metric of completion
There is no "done"
The community lives and grows and flexes and changes and forks and splits and shifts
How do we measure success?
We had 30+ devs using our code at Hyperledger, we wanted more: more devs, more interaction, more engagement
We would kill for someone to ask a question on the weekly conference call - for months it was like a radio show with two nerds and no callers
Then one day, before we could get to them, community members started answering newbie questions in Slack:
"Where is the Agent module?"
"Can I use javascript for X?"
"Where is the installer for Y?".
All of the sudden, we had devs sharing their code, answering questions, offering to help with the FAQ
THEN THEY STARTED CONTRIBUTING CODE!
And we freaked out because while we could accept it, we had no process to do so that was public (a big no-no) - so we scrambled
But it isn't over
We want to make this a place the community feels they own, a codebase they want to build on, a community they want to be a part of
We are redoubling our efforts to "groom" the community to be more helpful - thanking folks publicly for sharing tips and fixes, calling out big ideas on calls and making sure we mention frequently "this is your community" - if they own it they will treat it better
A few months ago a team working on our software announces $100k in feature bounties (they need specific features not on our product roadmap to do stuff they want - it is more efficient to offer $ to the community to build it)
THIS IS AMAZING and scary
Amazing: people are "playing with our toys" and want to make them better
Scary: They might take our toys in a different direction and do things we didn't want or plan
Which means we have to work harder to keep things moving in directions we want, delivering code faster, explaining our decisions in the open, starting with "WHY"
This is one of the few times in business where the old saw, "if you are explaining you are losing" falls apart
Explaining = winning
We are now getting attention from big companies (fintech and big tech)
We have to work doubly hard to make sure they understand they are joining us (not the other way around - we do not and will not be co opted)
We have to work extra hard to reassure the community members that we won't let them throw their weight around
While at the same time suggesting they let BigCo know what kind of features they are looking for
The code exists or it doesn't.
The documentation exists or it doesn't.
That's the "hard" stuff - the stuff you can touch
The stuff that shows commitment when you aren't there
The SOFT stuff, the people stuff is infinitely harder.
It is ALL Soft Stuff
The community is welcoming to new and returning members or it isn't.
People say thank you or they don't.
People want to be recognized for their contributions.
Jerks need to be intercepted immediately
Quiet ones need to be encouraged to just say hi and why they are interested
Our original goal in this was to project authority and credibility about our project and build a developerbase to make it sustainable, resulting in a bigger, faster, strong ecosystem
now we are wishing people "good luck" on moving house and congrats on having kids
now we have people in 11 timezones asking questions and getting answered before we (our company) can respond
now we have teams from BigCo looking to start developing things they need in the code
now we need to have "scrum of scrum" meetings where the different teams can make sure we are all aligned
now we have folks offering to hold meetups in cities where we don't have staff because they know they can get 10 people to a coffee for a talk about blockchain and identity
now we are looking at who to deputize as code maintainers and community leaders in case something happens to us (people quit, get hit by buses, etc.)
There is no "done" with community
As I said above, hope this helps.
- Sean