[OPEN-ILS-GENERAL] Draft rules of governance for Evergreen Software Foundation - for discussion

Dan Scott dan at coffeecode.net
Fri Oct 8 12:14:33 EDT 2010


On Thu, Oct 07, 2010 at 05:46:57PM -0400, Joe Atzberger wrote:
> >
> > > > The question is: should a library be able to be a voting member (one
> > vote)
> > > > if the extent of their contribution to the community is simply to use
> > the
> > > > Evergreen system being run by their consortium.
> > >
> > > My sense is, yes.  They have a legitimate stake in the project.  And it
> > > won't be as if most institutions that are concerned enough to exercise
> > their
> > > vote will stay otherwise uninvolved with the project.  The Koha community
> > > has several prominent examples of people who started as "just users" and
> > end
> > > up as regular contributors.
> >
> > I believe that we need to encourage more participation in and
> > contribution to the Evergreen community, and that the currently drafted
> > membership rules are one small way to encourage that.
> >
> > I don't see what relation your Koha example has to the proposed
> > membership rules, unless you think that the person would have said to
> > themselves "I'm just a user and not a member, therefore I'm not going to
> > contribute"...  which seems unlikely to me.
> >
> 
> Yeah, that wouldn't make sense.  The question at hand regards characterizing
> "non-contributing" users (NCUs).  Will there be a lot them?  Will they bog
> us down?  Firstly, we're talking about a subset of "non-contributing" users:
> the ones who will actually exercise the membership I would extend to them
> and use their vote.  Secondly, if you are active enough to be voting, I
> consider it quite likely you will become involved in other aspects of the
> project, whether that is sending code, building test systems, testing
> features, training users, hosting the conference, editing documentation,
> wrangling bugs, translating strings, helping new users with installs or
> whatever.  The Koha community illustrates this pretty well.

> But basically, I see responsible membership in the Foundation as a form of
> participation in the community itself, not as a payoff for some other
> activity.  Membership in the community should only require that you have a
> legitimate interest in EG.
> 

You're comparing an attempt to set up the rules of engagement for a
legal entity that handles financial and legal matters (the Evergreen
Software Foundation) to an informal community (the Koha community).
There is and always will be (well, as long as there is interest) an
Evergreen community with no barriers to participation in the Evergreen
community.

It is from this community that the members who would
participate in the legal and financial decisions of the Evergreen
Software Foundation would be drawn, under the proprosed draft. And the
board would in turn be elected from these members.
> 
> > For your scenario, in the rules as currently drafted, the contributor
> > would become eligible to become a member, and the library that employs
> > the contributor would also become eligible to become a member. In the
> > currently proposed model, membership is a reward/incentive (slim though
> > it might be) for being an active participant in the project. That
> > ensures that when members vote, they have a legitimate stake (in the
> > form of having contributed effort / resources) in the project, rather
> > than just a passive role. And further, as only members are eligible to
> > be elected Board members, it ensures that the Board would be made up of
> > people who have participated actively.
> >
> > Take the requirement for active contribution away, and the meaning of
> > membership becomes watered down significantly.
> 
> 
> I don't think I would want to see a lot of contributions that were
> significantly incentivized by voting membership.  This is one of those "be
> careful what you wish for" type of things.  If you're writing patches to get
> membership, I'd question both the patches and the membership.  But I agree
> whatever real incentive exists is smallish.

If the patches that were written are significant and sustained, then a)
great, that helps Evergreen, so who cares about the motivation? and b)
that would meet the requirement for membership.  If the patches or
documentation or translations or whatever were trivial, then they
wouldn't be a significant contribution and wouldn't meet the requirement
for membership.
 
> Users who stake their enterprise on the utility and longevity of our project
> are not, in my opinion, so much disposable solvent.  They are in many ways

I don't see where, in the draft rules of governance or in any previous
emails in this thread, users were ever characterized in anything
remotely close to this fashion.

> more committed to its long term success than a hypothetical developer of a
> given feature or bugfix.  As the userbase grows, I think we can reasonably
> expect to see more contributions from coders who are not
> career-evergreenists, perhaps not even career library techs, just people who
> had to integrate w/ X or successfully run on unpopular platform Y.  I don't
> see any reason to privilege that group over, say, a director who has kept
> their library on EG over 3 major versions (should we be so lucky).

I don't think one group actually is privileged over the other group.
Running a production Evergreen library instance qualifies the library
for membership, in the current draft.

> One other entailment: under your model, the Foundation would be required to
> police membership for minimum activity and against inactivity.  I find it
> problematic trying to determine, say:
> 
>    - how many patches a first period of membership should require?
>    - how many for a second?
>    - how long should the periods be?
>    - or should that be lines of code instead of patches?
>    - what's the equivalent number of strings translated?
>    - or pages documented?
>    - etc.

There are other, larger free software organizations that define
organizational structures in which a member is recognized after
significant and sustained contributions to the community:
https://wiki.ubuntu.com/Membership and
http://wiki.sugarlabs.org/go/Sugar_Labs/Members, for example, follow
this model. As other groups have been able to solve this problem
successfully (using qualitative measures instead of trying to use some
strictly quantitative approach would probably be a good start), I'm
confident the proposed Nomination and Membership Development Committee
could do the same.


More information about the Open-ils-general mailing list