[IAEP] Funding - and governance
Bert Freudenberg
bert at freudenbergs.de
Wed May 28 11:53:45 CEST 2008
On 28.05.2008, at 10:42, 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
That article is spot-on. These paragraphs describe what many
volunteers feel with respect to OLPC - despite of many OLPC employees
at 1cc trying to be as open as possible, even using irc to chat if
they sit in the same room etc:
============
When the consortium was created, paid programmers were moved into a
single office. It was now quicker and more efficient to discuss a new
feature or a design decision at a whiteboard or blackboard or over the
top of the cubicle. Development became quicker and more efficient for
people who worked in the office and more difficult to track, follow,
and participate in for anyone working from remote or who had less time
to devote.
Part of being "more equal than others" was having easier access to
information and status and to the other people working on the project.
While the project was still "open" to contributions from its
community, volunteers had a more a difficult time following the
project's development.
=============
We must avoid a similar situation with Sugar Labs. There are no plans
to stuff developers into one office, they are paid by different
entities for now, so there is no immediate danger. Btt the planning
forward should take this into account.
Thanks for forwarding this essay.
- Bert -
> 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
>>>
More information about the Its.an.education.project
mailing list