Subject: Re: Nessus 3.0's failed community
From: Michael Bernstein <webmaven@cox.net>
Date: Wed, 30 Nov 2005 10:52:34 -0800

On Wed, 2005-11-30 at 16:46 +0900, Stephen J. Turnbull wrote:
> >>>>> "Michael" == Michael Bernstein <webmaven@cox.net> writes:
> 
>     Michael> In short, the company is now forbidding the new employee
>     Michael> to do the very thing that likely got them hired in the
>     Michael> first place.  This is, to say the least, at least
>     Michael> somewhat hypocritical on the part of the company,
> 
> I violently disagree with that statement in this context.  Brian
> started the discussion by talking about a hypothetical FSB "no matter
> how open".  A well-intentioned FSB is not going to be _forbid_ding
> community participation.

Again, you are missing the context, which was 'participate on *company
time*'. This is not a hypothetical, by the way. I am aware of at least
one reasonably well known FSB that has an explicit policy of
discouraging most of their employees from participating in the project's
associated community venues such as mailing lists and IRC during work
hours. Employees can continue to participate in the community on their
own time if they like.

Here is how this works out in practice:

Joe uses project foo in the course of his work. He participates in the
foo mailing lists to get answers to help him do his job, and also
answers questions posted by foo-newbies. His employer thinks he's a
miracle worker, and has no problem with how he's spending his time
because he's getting the job done. Joe actually likes his job, even
though he self-identifies as a foo-hacker.

Joe gets noticed as a foo-expert on the mailing lists, and gets hired by
fooCo.

Now Joe still uses project foo in the course of his work, but is not
allowed to participate in the mailing lists on company time. He is told
fooCo company policy is to get answers to his questions by asking
co-workers instead.

Joe continues to participate a little in the mailing lists on his own
time to answer foo-newbies' questions, but it's not the same. He is no
longer engaged with the community.

Perhaps, if the foo project depends on the bar toolkit or language, Joe
can make a case for participating in the bar community on company time
to help him do his job.

While Joe is still getting the answers he needs to do his work, notice
what has been lost here: His own questions and the answers he got from
other non-fooCo experts are no longer being captured in the mailing list
archives!

> I see no hypocrisy even if the net effect is a large withdrawal of
> resources from "the community".

Instead of thinking of 'community' as some fuzzy-wuzzy feel-good
concept, think of it as a 'community of practice'. Even though fooCo's
products and services don't depend directly on the foo community, that
community is a very important part of the 'whole product' that they are
selling, and failing to apply the 'Engagement' lever to grow the
community and improve it's vitality is a *big* mistake.

But, leaving that aside, keep in mind that I was not speaking of any of
the 'inevitable' reductions in participation you brought up, ie. the
day-job effect, Joe's conscientiousness as an employee, and the
psychological need to find a 'hobby' different from his 'work'. I'm only
talking about the entirely avoidable effect of a particularly damaging
policy, and only described that policy as 'hypocritical'.

> As I see it, the question is whether the net withdrawal needs to
> happen to achieve the goals of company and employee, and how to
> prevent it if not.

See, to my way of thinking, to the extent that some reduction in total
community activity on the newly hired employee's part is inevitable, I
see his remaining community activity gaining hugely in value, so there
is no 'net withdrawl', instead, we have an increase in the
signal-to-noise ratio.

>     Michael> Contrast the results of that policy with one of
>     Michael> encouraging employees to participate in the community on
>     Michael> company time as a necessary part of their jobs. This
>     Michael> creates a virtuous cycle. Community members that are
>     Michael> hired suddenly become *more* valuable to the community
>     Michael> instead of less (even if they have less actual time to
>     Michael> participate), and the community in turn becomes more
>     Michael> valuable to the company.
> 
> Sure, I believe it happens; what we need to figure out is "how and
> why"?  Will it work for _any_ FSB, or are there classes of OSS (or as
> Larry Augustin pointed out, OSS business models) for which it won't
> help enough?

Well, that is a different question than the one I was answering when I
jumped into this thread. Specifically, I was answering Marshall W. Van
Alstyne's question (paraphrased) "What levers can firms use to grow
their associated developer communities?"

I will second your observation that effective communities will tend to
grow around platforms, rather than applications, except to the extent
that applications can become platforms in their own right.

In fact, this can be (and I believe has been before) generalized as the
maxim 'make your application a platform', which is as true for
proprietary software companies as it is for FSBs.

Another way of looking at things is to observe that if you refactor your
application until one or more platforms (libraries, toolkits,
infrastructure) falls out, adoption of the platforms by a community can
cause your application (that you don't get many direct code
contributions to) to improve as a side effect.

- Michael Bernstein