[Ocaml-biz] securing COCAN

[Brandon J. Van Every]

Brandon J. Van Every wrote:
> Tony Edgin wrote:
>
> > Modified proposed preliminary game plan:
> >
> > 1)  In  parallel,
> > 	a) Determine market
> > 	b) Bring COCAN people on board if they aren't already a
> >        part of this mailing list.
> > 2)  Determine useful set of tools for an Ocaml toolbox for
> >     this market.
> > 3)  Find existing best fit tools.
>
> For action items, I think we should cut it off here.

I think we drop (1)(b) from the list, at least as any kind of
constraint.  We ask them to come.  We don't worry about if they come.
We use the COCAN wiki to reposit all of our permanent, "community
memory" results.  COCAN wiki becomes us.  They come to the mailing list
when/if we are the critical mass of serious business discussion.  When
the wiki is littered with all sorts of references and links generated by
us.

If COCAN surprises me and creates a mailing list, we dump this list and
use the COCAN list.  The goal is to unify the effort.  It's totally
undesireable to have 2 groups, it's only a question of how the groups
become unified.  If we simply *act*, and use the COCAN wiki, they will
unify with us per our guidance and input.

So our action items, for now, are simply:

1) Determine market
2) Determine useful, desired OCaml toolbox for this market
3) Find existing best fit tools

I don't think these are really 'parallel' problems.  I see them as
mutually recursive.  We have to work these 3 things until we come to
some consensus on strategy.  If we get that far, within 1 month, then we
can execute the strategy.  If we can't build the consensus in 1 month,
we're DOA.  1 month is an outer, "absolute drop dead" bound.  I'd like
to see results sooner, I just think 1 week is too aggressive an
expectation for building consensus.

If we agree that this is the plan, we put it up on the COCAN wiki, say
that we're doing it, explain the 1 month timetable, and invite others to
join us.

Schedule risk: if COCAN people sloooowly, lugubriously roll in, giving
contributions late in the month, or even after our self-appointed
deadline expires, then we have to go through the consensus building
process all over again with a lot of new players.  That's valuable for
long-term unity of purpose, but draining to morale in the short term.
The defense against that is to begin executing a plan that makes a
strong show of "really being an effort, so why don't you just pitch in?"
In other words, if we are performing, they'll go along with it and not
just try to start everything all over again.  Or, if they try anyways,
they'll be made to feel unreasonable and may concede / compromise.

Risk avoidance strategy: use the wiki early and often.  Dump regular
info onto it, so nobody says, "Heeeeey you guys weren't including us,
what's going on??"  Or again, if they say it anyways, show how steps
were taken and their complaint is unreasonable.  Then they may concede /
compromise.

If I sound adversarial about all of this, when discussing COCAN, INRIA,
etc., it's because I fully expect conditions *will* be adversarial.  At
least in part.  People have their egos.  The dance is really about
securing the buy-in of various parties.  Back in Python-land, we didn't
fail to do the legwork / gruntwork.  We did lots of that.  We failed to
secure the needed buy-ins.


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"The pioneer is the one with the arrows in his back."
                          - anonymous entrepreneur