Trust In Communities

I’m sure a lot has been written about the subject of trust within communities.  As I’ve been working through the community launch plan for forge.mil (more updates on that in a future post), I’ve been thinking quite a bit on this, and two things spring immediately to mind: ‘default to public’ and ‘own your words/contributions’.

I’ve helped counsel previous employers and others on starting communities, and inevitably, the question comes up of ‘how much of this project should be public’.  My answer is always the same: "All of it should default to public".  Fred Wilson, a Venture Capitalist in New York, recently blogged about this, and I loved his take on it, which was informed by reading a pre-release version of an upcoming Jeff Jarvis book which quotes co-founders of both Flikr and Facebook on this subject.  I encourage folks to take a look at Fred’s post, but for me, the money quote was:

"The value of public discourse and engagement around content/information/knowledge vastly outweighs most of the privacy concerns most of the time."

Don’t get me wrong, there are plenty of times (and reasons) for content to be access controlled from free viewing, but I would argue those cases don’t constitute a community – they are more like project or implementation groups.  If your goal is truly to create a community around something, you need to trust the members of your community, and they need to trust you.  There is no surer path to the destruction of a vibrant community than to try and hide things that don’t need to be hidden.

The other area of trust which is a big deal for me is personal responsibility by the members of the community – specifically in owning your own words and contributions to the group.  Because of this, I have a very strong belief that anonymous posting in discussion forums has no place in communities.  I do run afoul of some of my colleagues at CollabNet at times for this view, and I do grant them there may be cases within project or implementation groups where this makes sense, but in general, requiring people to own their words and contributions is a critical piece of establishing trust in a community.

I believe there is a good reason the designers of our CollabNet SourceForge Enterprise tool decided the minimum permission needed to post to discussion forums is ‘a logged in user’.  By enforcing this with tools, and a diligent community manager who works to make sure that ‘anon spam’ doesn’t start to creep in, I believe the trust level of the community (and therefore, the productivity) is increased.

Interestingly, there may be some challenges with the SoftwareForge.mil piece of the forge.mil initiative in regards to ‘default to public’, but the owning of words/contributions has been pretty well settled – the Department of Defense isn’t big on anonymous posting. icon smile Trust In Communities   We have had some interesting discussions with DoD regarding how we also bring reputation management into the picture for the forge.mil properties, and I think that is going to be the basis for some critical trust building going forward for this project.

My bottom line (from the ‘obvious statements department’):  If you don’t trust your community, they won’t trust you, and no amount of fancy marketing or public relations will be able to fix that.  I continue to encourage companies & individuals interested in utilizing the tremendous potential of communities to heed this.

Posted in TeamForge
3 comments on “Trust In Communities
  1. I definitely agree, Guy.
    One of the counter-arguments that frequently comes up is something like this: “people need to download my packages and report bugs without the overhead of joining the community.” A Community Manager needs to push back pretty hard on that idea, because what that really means is, you don’t have a community at all–you just have a down-load site!
    In a community, it’s extraordinarily anti-social, for example, simply to post bugs anonymously. If you’ve found a bug, the sociable thing to do is to help the developers understand your report, and to stick around long enough to confirm that their changes actually fix the problem. That sort of cooperative consumption is “contribution” at least as important as the actual coding. If, as a Community Manager, you grant your users the right to lob smoke-bombs over the wall and run away, all you’ll get is smoke. A community has to be an organic, living thing, like a farm. You can’t run a farm when the soil blows away. You can’t run a community when the “members” run away. The life of the community is in the contributions.

  2. Carey O'Brien says:

    All the points you’ve made are valid and appreciated. That being said, I will submit to you that taking a public stance by sharing one’s own contribution or questions doesn’t come easy to everyone. This is especially true for those of us who grew up in corporations where intentional visibility to oneself and most especially others was not very PC. Open communication was not the norm. This can also be true for those who are contributing in a foreign language. It can require a certain level of confidence in your capabilities to actually hit the ‘Post’ button.
    How is this challenge overcome? I believe the best method is for community members to pay attention to the culture of each community they would like to contribute to. Some communities foster a very easygoing culture where all contributions are appreciated. Whereas others expect members to achieve a certain level of technical or background experience before contributing – and can provide rather deflating, terse comments to contributors who do not.
    So, people who don’t yet feel confident contributing in this open world can build up their confidence by starting out in smaller, less intimidating communities. Eventually, they will realize that all contributions are truly valuable.

  3. Guy Martin says:

    Thanks Carey,
    You are very correct about the reticence of some community members (especially new ones) to participate in the process. Quite frankly, I think this is one area where a good community manager earns their paycheck. They need to not only encourage folks to participate, but also work with project/site leaders to champion a more open process.
    I’ve found that one way to get project/site leaders and management to understand the value in a more open & collaborative process is to highlight the business benefits of such a system. There are a lot of case studies out there (especially communities like the Linux kernel) that have proven the inherent business value of encouraging open collaboration.
    Thankfully, in the case of our DISA forge.mil initiative, the sponsor (Rob Vietmeyer in the DISA CTO office) has set out to create an ‘internal Sourceforge.net’, so we already have management support for doing things in an open way. The challenge I’ll most likely face as the community manager is getting the project leads on board with this method of doing things, and then also encouraging individual contributors to do this as well.
    To that end, we are starting with a small number of projects (no more than 5) so that we can provide the necessary level of ‘on-boarding’ expertise. The hope is that if we get a small group of people participating in an open way, that will show future projects coming into the site the way to do things.
    Thanks again for your comments!

Leave a Reply

Your email address will not be published. Required fields are marked *

*

CAPTCHA Image

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

connect with CollabNet
sign up for emails
looking for something
conversations

CollabNet: Don't forget to register for our upcoming Certified #Scrum Master Course in Baltimore, MD! Apr 28-29 http://t.co/MJTfBMRAz9
Date: 22 April 2014 | 10:30 pm

CollabNet: Register today! How the Government is Utilizing Open Source Webcast Series http://t.co/gQ89IyrsvM Thursday – April 24th, 2014 – 2:00pm ET
Date: 21 April 2014 | 10:15 pm

CollabNet: @dribback1: discusses "The #Agile Regression: How to Avoid Moving Backwards" in our blog http://t.co/WMBdc8JmrI
Date: 21 April 2014 | 5:42 pm