[IAEP] Funding - and governance

Wed May 28 10:51:51 CEST 2008

Thanks for the pointer to Mako's article.  I wasn't aware of it.  I just
have scars to prove it :-(....

Here's another failure mode:

o organization has a revenue stream to work on a particular project;
said organization then decides to go in a different direction (from
where the money was intended to be spent).  Problem...  Example: Motif;
TOG was supposed to take the Motif royalty stream and spend it on
maintenance and enhancement of that project; instead, the money went,
(as far we can tell) to fund other projects the organization thought
more important..

Software projects should have a life of their own, independent of
funding source.
                            - Jim

On Wed, 2008-05-28 at 01:42 -0700, Seth Woodworth wrote:
> I've been trying to wrap my brain around this idea for content-based
> projects.  I've had a few people that I respect take the same stance
> as Jim.  Mako wrote a pretty good article on the subject a few years
> ago that I think has some bearing on the situation:
> 
> http://mako.cc/writing/funding_volunteers/funding_volunteers.html
> 
> 
> 
> On Wed, May 28, 2008 at 1:27 AM, Jim Gettys <jg at laptop.org> wrote:
> > Wade,
> >
> > I've seen projects *die* from having centrally funded development staff
> > conflated with project management and governance.  This was the X
> > consortium model (though it made other mistakes too).  The scars are on
> > my back, and I'm personally partially responsible for that mistake. And
> > also as a result of that mistake, I've had a hobby of observing (and
> > participating in) governance of large free software projects over the
> > last 8-10 years (e.g. Gnome, X.org).
> >
> > Several things can happen when governance and development are conflated:
> >  o companies/organizations think to themselves: "I paid good money to
> > the consortium", and tell them to do it rather than staffing up to get
> > things done themselves.  Net result: no community, and endless arguments
> > over what work the central staff should do; often over pet projects the
> > funding organization can't afford anyway, looking at that pot of money
> > as a way to get what they think they want.
> >  o companies/organizations think to themselves: "Other people are paid
> > to do it, I won't help", (either by people or money).
> >  o it becomes against the economic interest of the funding
> > companies/organizations for the software to continue to evolve.  So they
> > oppose change.
> >  o the funding organizations, having put good money in to fund people,
> > now believe they have good reason to "vote" and control what happens.
> > This fundamentally dis-empowers the community.  And then, you get to
> > start over building community and an organization from scratch. While
> > successful forks are possible, boy, are they hard (again, first hand
> > experience).
> >  o "us" v.s. "them".  We see lots of that right now with OLPC; as our
> > efforts have had to shift toward issues arising out of deployment, it
> > has had the effect of dividing the community who develop the code and
> > those who have to deal with the day-in-day out support issues.  Lots of
> > frustration on both sides.  But more pernicious is control vested in a
> > single organization of funded people; their ideas become much more
> > likely to "ship" than other contributors, dis empowering both individual
> > volunteers and organizations. Great people drift off into other
> > projects, and you die slowly.  Did you know Guido Van Rossem was once an
> > X hacker?
> >
> > In general, I'm much more comfortable with resources in the organization
> > responsible for Sugar going toward community building.  If you look at
> > Gnome, or new X.org, most of the (relatively nominal) money they get
> > from sponsors toward meetings and conferences, toward enabling travel of
> > volunteers to those meetings, hardware for central facilities such as
> > servers.  They also act as dispute resolution forums, (though in well
> > run projects, those are pretty rare events).  The bulk of the work is
> > done on by people with direct stakes in their outcomes, whether
> > commercial or volunteer, and all are peers.
> >
> > Having said this: sometimes it has made sense for open source
> > organizations to fund work no one wants to do (e.g. test suites, or
> > hiring copy editors to improve documentation, or...), though Cairo has
> > shown even (some or all) those can be done by well disciplined projects.
> >
> > So I'm very happy if Walter can get money to help push Sugar forward:
> > but I think it is a grave mistake if we have governance of Sugar in
> > *either* Sugarlabs (*if* it becomes a development organization by hiring
> > developers) or OLPC's hands.  Sugar as a free software project has to
> > become its own thing as an independently governed entity.  And this will
> > solve many conflict of interest and trust issues inhibiting growth of
> > the community, and allow us all to work together even if funding sources
> > are from highly competitive sources.  You put the two together
> > (governance and major funding), and it spells t-r-o-u-b-l-e.
> >                             Best Regards,
> >                                     - Jim Gettys
> >
> >
> >
> >
> > On Tue, 2008-05-27 at 17:43 -0700, Wade Brainerd wrote:
> >> On Tue, May 27, 2008 at 3:25 PM, Walter Bender <walter.bender at gmail.com> wrote:
> >> > Good question to which there is not a definitive answer yet. The model
> >> > I have been kicking around in my head is to have a small team that
> >> > keeps its focus on top the various infrastructure needs of the
> >> > community and raises money to support community gatherings and such
> >> > incidentals as the filing of trademarks (expensive), etc.
> >>
> >> I believe this is one way in which non-profits often falter, compared
> >> with their for-profit competitors.  I have worked with non-profits who
> >> have high caliber "idea" people and a regular supply of volunteer
> >> labor, but no core technical staff.  When each volunteer engineer
> >> burns out and leaves, their work is discarded and begun anew by the
> >> next volunteer, because nobody is there to carry it forward, or
> >> explain it to the next person.
> >>
> >> The same issue applies to companies who employ a lot of contractors.
> >>
> >> You need at least one senior representative of each discipline
> >> required by the project, full time and on staff.  For Sugar, I think
> >> this includes project management, user interface design, artwork,
> >> shell interface programming, system programming, packaging (and
> >> release management), documentation, infrastructure, and activity
> >> development.
> >>
> >> Also, I think that activity development must be a core part of the
> >> team.  Someone needs to be responsible to develop the "killer apps"
> >> that sell the platform (where would the Wii be without Wii Sports?),
> >> and someone needs to be able to take over important projects when
> >> volunteers leave.
> >>
> >> Regards,
> >>
> >> Wade
> >> _______________________________________________
> >> Its.an.education.project mailing list
> >> Its.an.education.project at lists.sugarlabs.org
> >> http://lists.lo-res.org/mailman/listinfo/its.an.education.project
> > --
> > Jim Gettys <jg at laptop.org>
> > One Laptop Per Child
> >
> > _______________________________________________
> > Its.an.education.project mailing list
> > Its.an.education.project at lists.sugarlabs.org
> > http://lists.lo-res.org/mailman/listinfo/its.an.education.project
> >
-- 
Jim Gettys <jg at laptop.org>
One Laptop Per Child