[Members] Re: disconnect from board to active developers

[Egbert Eich]

Hi Donnie,

thank you for bringing this up!

Donnie Berkholz writes:
 > Egbert Eich wrote:
 > > Do we actually know any precedence where a free project employes
 > > hired people to do development work - together with contributors
 > > from the community?
 > 
 > Mozilla.
 > 
 > In fact, there's a discussion happening related to this on another list
 > right now. They cite projects that are worthwhile but don't see
 > developers coming forward, such as accessibility. I'll paste a large
 > chunk of the email:
 > 

[...]

 > 
 > By funding work in this area (through "grants" in the form of short-term
 > consulting contracts) and providing other support (e.g., sponsoring
 > people to attend conferences and developer meetings) we've been able to
 > build up a larger pool of people who are excited about doing
 > accessibility-related work and are accomplishing useful things (e.g.,
 > improving Firefox accessibility on Mac OS X). This has also led to a
 > significantly increased positive perception of Firefox among the
 > community of people concerned with accessibility issues.

The 'other support' that is mentioned above (ie  sponsoring people 
to attend conferences and developer meetings) is what X.Org has
already done (not very effectively) and there are no doubts that
that this should increase.
I would favor a 'reward' or 'bounty-like' model in most cases.
however I could imagine that for certain tasks - especially tasks 
for which we don't volunteers for and which can be well defined
in terms of the expected results - we could put our money to
work and fund a student or somebody to do this work. I'm thinking
here of jobs like converting the different documentation formats 
to something we can process more easily.

 > 
 > I think this type of approach can be successfully replicated in other
 > areas, and I think there are likely other areas in the Mozilla project
 > and beyond where it might make sense. Here are the main elements that I
 > think are key to making it work:
 > 
 > * Have a strong lead developer who can identify promising areas in which
 > to fund work (basically areas which have a high potential payoff but no
 > one working on them) and also find promising people to support. ... In
 > some cases we start with the project and attempt to find a
 > person; in other cases we have a promising candidate and try to find a
 > project that matches their interests and is of use to us.

I'd have my reservations with the latter model. Having a candidate
and finding a project to match his interest can be  too easily abused
to support a friend who needs a job. 
For something like this to materialize in our organization the 
processes and the work and decisions of the Board needs to become 
a lot more transparent.

 > 
 > Note that this approach is the exact opposite of ideas like code
 > bounties where you throw a wish list out to the world and let people bid
 > on items. Based on my experience I think that's an unworkable approach.
 > 
 > * Keep the amount of funding within reasonable limits. Almost all of the
 > "money for code" arrangements we do are for relatively small amounts, in
 > the $5-15K range per project: big enough to make a difference to someone
 > who's a student or doing Mozilla development as a spare time activity,
 > but not big enough for anyone to be able to live off of. Our goal is not
 > to support a group of full-time developers. Instead our hope is that
 > people who'd like to do this sort of work full-time will use their work
 > with us as a springboard to paid employment with companies like IBM,
 > Sun, Novell, etc (or, for that matter, with the Mozilla Corporation).

This is certainly different from the model of hiring people for
development that existed in the old X.Org. 
The incentive to use this as a chance to qualify oneself for a better
paid long term employment are high. Specifically limiting this to
students or similar individuals and setting clear expectations will
avoid many of the problems that I had envisioned.
Agreed, such a model - combined with sufficent community involvement 
and a consensus on both the goals and the candidate - may work.

The merit of a model with only very short term commitments is that
it can easily discontinued when it doesn't work out.
If the expertise on the architecture resides outside among a group
of lead developers who are outside this funding model no stong 
dependencies are created.

 > 
 > * Balance "money for code" arrangements with other forms of support. A
 > lot of the funding we've done is for things like helping to pay people's
 > travel expenses to attend conferences and meetings. We've found this is
 > a good way to build a sense of community among the various developers
 > and help get them connected into the informal social networks in
 > whatever field they're working in (in this case, the broader "assistive
 > technology" space, which contains commercial firms, nonprofit
 > organizations, and government agencies).

Yes.

 > 
 > Those I think are the main factors for successfully doing this. There
 > are some other items as well, like having a clear technical roadmap and
 > an overall vision and strategy that ties what you're doing back to the
 > main project and its goals. However I think to some extent these can
 > emerge organically as opposed to be planned out from the very beginning;
 > that was certainly the case for our accessibility work."

True.

As it looks like different models exist which are worthwile to be
examined further. However I think not only abroad consens for this
needs to exist among the community but also a push towards this
needs to come from the community.
Presently - as the subject says - there is a big disconnect between
the Board and the community. Some Members of the Board don't seem to
have the right feel for what our community is.
Too often Board people look for answers among themselves or among their
personal contacts and don't take the community into consideration.

Cheers,
	Egbert.