[Eg-oversight-board] Fwd: Re: Release manager, Package releases vs Software releases, Membership fees

Kathy Lussier klussier at masslnc.org
Thu Aug 15 16:04:55 EDT 2013


Hi all,

I'm resending my response to the public and archived Oversight Board 
list. I just realized my first e-mail didn't go there.

Regards!
Kathy


-------- Original Message --------
Subject: 	Re: [Eg-oversight-board] Release manager, Package releases vs 
Software releases, Membership fees
Date: 	Thu, 15 Aug 2013 12:17:19 -0400
From: 	Kathy Lussier <klussier at masslnc.org>
To: 	Elfstrand, Stephen F <stephen.elfstrand at mnsu.edu>
CC: 	Evergreen Oversight Board +SFC (evergreen at sfconservancy.org) 
<evergreen at sfconservancy.org>, Lazar, Alexey Vladimirovich 
<alexey.lazar at mnsu.edu>, Curie, Carrie L <carrie.curie at mnsu.edu>



Hi Stephen,

Just to be clear, I do agree with the need to build funds and for the 
EOB to find ways to support strategic development projects. You get no 
arguments from me on that front.

> We talked about the need for funds to for instance, to use to match 
> grants we might get. One idea is to sell advertising space on the 
> Evergreen web site to vendors.
>

You had mentioned this idea at the last EOB meeting. In a subsequent 
conversation with Dan Scott after that EOB meeting, I learned that there 
are other open source projects that have successfully highlighted 
donors/sponsors on their pages. It might be worthwhile to investigate 
this option after the community web site's conversion to Wordpress is done.

Based on my involvement in the process for getting conference 
sponsorships, I'm guessing we would need to avoid to use the work 
"advertising" and describe them as sponsorships where the donor is 
acknowledged on the web page.

> Another idea is to have a membership fee. Kathy you're right to say 
> that we shouldn't charge people to run Evergreen. I'm not suggesting 
> that.
>
> As a public entity I can pay a membership fee but I just can't donate 
> money to worthy causes. So if there was a membership fee, I would pay 
> it.  I guess to flesh out my idea a little I think a membership fee 
> should be tied to voting. Organizations and individuals who wish to 
> vote on community business should be members, so should the EOB 
> members. Remember we pay 10% of our total billings to the Software 
> Freedom Conservancy, I don't see a problem recouping that money back 
> through membership fees. I'm not talking about large amounts but 
> something would help.
>
> Crediting organizations for in-kind efforts does seem fair, but 
> unfortunately doesn't help raise actual dollars to match with grants 
> or sponsor development and documentation.
>

Thank you for the further explanation on the membership fee. I guess I 
had misinterpreted some of this idea.

I still am a bit uncomfortable to tying a fee to voting. I could see 
cases where an institution may not be able to put a membership fee into 
its budget, but might have staff who has consistently contributed 
documentation throughout the year. For me, it's would be hard to say 
that the institution is not allowed to vote when they are contributing 
to the community.

But there might be other ways of setting up a membership fee 
infrastructure, perhaps building it into sponsors highlighted on the 
Evergreen web site. Perhaps acknowledgement of different levels of 
membership.

Kathy



Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
klussier at masslnc.org
Twitter:http://www.twitter.com/kmlussier

On 8/15/2013 11:33 AM, Elfstrand, Stephen F wrote:
>
> Hi Kathy,
>
> Thanks for your response to my suggestions.
>
> I didn't generate a lot of discussion with my suggestions. Yours is 
> the only response I've received. I guess I'm just out of step with the 
> thinking of the rest of the EOB and the developer community.
>
> I hope everyone takes my comments as constructive criticism. I do 
> appreciate all the hard work and professionalism that the developers 
> and the community at large have shown. I realize that many great 
> things are going on. My goal is to take it to the next level.
>
> As an administrator, I would like to see _Package_ releases not just 
> _software_ releases. For example
>
> _At PALS we run only standard releases, and have had upgrade scripts 
> them fail.  We try to exercise due diligence and figure things out for 
> ourselves before we burden the Community with questions but have had 
>  to go to the developer list and see if someone might know why it 
> would fail.  We've had to find someone who knew why and apply an 
> undocumented fixes. This makes it difficult to treat Evergreen 
> upgrades in a routine manner and adds unnecessary costs to us and 
> service delay to our users.  It makes one wonder whether the upgrade 
> scripts are adequately tested.
>
> I've suggested before that someone not involved in a recent release 
> should run the upgrade scripts to make sure the instructions are 
> complete and correct and that the scripts work. PALS would be willing 
> to be one of these testers..
>
> -Acquisitions was released before it was usable, it was much too slow 
> for large invoices.
>
> -Authorities was not working well yet was released. Batch downloads of 
> new authority records should change all the records linked to it. I 
> know for instance that we lost a highly prestigious customer because, 
> at least in part, the authority control system was not working.  They 
> went to OCLC WSM instead.
>
> _Technical and end user documentation is way behind the code, yes it 
> is getting better thanks to the community. Still, being forced  to 
> consult  2 or 3 versions of incomplete documentation is just not good. 
> If we held software releases until the documentation was completed, it 
> would give the community motivation to get the documentation done.
>
> Giving the Board some money to use for critical development would be 
> helpful I think . The Board could supplement what is being done 
> voluntarily by the community and fill holes by sponsoring development 
> and documentation.
>
> "only one person submitted his name as a candidate for the position" 
> Yes, I imagine it's a lot of work to volunteer for. If the Board had 
> some funds, it could offer a stipend to the release managers and get 
> more candidates.
>
> We talked about the need for funds to for instance, to use to match 
> grants we might get. One idea is to sell advertising space on the 
> Evergreen web site to vendors. Another idea is to have a membership 
> fee. Kathy you're right to say that we shouldn't charge people to run 
> Evergreen. I'm not suggesting that.
>
> As a public entity I can pay a membership fee but I just can't donate 
> money to worthy causes. So if there was a membership fee, I would pay 
> it.  I guess to flesh out my idea a little I think a membership fee 
> should be tied to voting. Organizations and individuals who wish to 
> vote on community business should be members, so should the EOB 
> members. Remember we pay 10% of our total billings to the Software 
> Freedom Conservancy, I don't see a problem recouping that money back 
> through membership fees. I'm not talking about large amounts but 
> something would help.
>
> Crediting organizations for in-kind efforts does seem fair, but 
> unfortunately doesn't help raise actual dollars to match with grants 
> or sponsor development and documentation.
>
> The fact that Equinox is requiring documentation is its contracts is 
> great. I think every contract should include it. Let's set this as a 
> policy or best practice suggestion  as a board. Let's have a 
> documentation hack-a-thon.
>
> We are competing with the Next Gen LMSs as well as current ones. The 
> next gen systems are including knowledge bases for serials, OpenURL 
> linking, and ERM  in an integrated work flow,  as part of library 
> management. We need to move in that direction.
>
> _I think Evergreen needs to be able work with the OLE folks to use 
> Open Knowledge Base and incorporate these next gen features.
>
> _Academic libraries
>
> _ need a patron API to keep our patron database in sync with campus 
> registration systems before large will want to use it en mass.
>
> __effective Authority Control
>
> _ interaction with Campus financial systems
>
> _NCIP interactivity is critical to all of our potential customers in 
> Minnesota, without it they just won't consider Evergreen. PALS has 
> undertaken to help develop this.
>
> _ Large public library systems will not move to Evergreen without
>
> __a first class Acq system
>
> __effective Authority Control
>
> On the Discovery side we need to incorporate
>
> _fast SOLR based retrieval
>
> _come up with a framework for OPAC layout that will handle mobile 
> devices as a matter of course.
>
> _The OPAC should have the  ability to use APIs from 3^rd parties like 
> Summon for Web-scale discovery.
>
> VuFind does all this already. Why not package VuFind with Evergreen? 
> Do we really need to create our own OPAC?
>
> Or if we do, why not use a CSS framework like Bootstrap, which handles 
> mobile devices and is easier to customize.
>
> These is not just a theoretical concern for the future, We've already 
> lost several prospects to OCLC Web Scale Management.
>
> PALS is willing to work on development, quality issues and strategic 
> priorities, It just frustrates me when we have to spend time figuring 
> out things like upgrades that should be routine, or compiling 
> documentation from multiple sources, or features that are released 
> before they are ready for prime time.
>
> So the reason I want the EOB to have funds available to it, is for it 
> to sponsor _strategic_ development that may not be of immediate 
> concern to existing users but will position Evergreen to compete with 
> the Next Gen Systems being developed. This will help appeal to 
> potential customers not just current ones.  Appointing the release 
> manager and paying a stipend will give the EOB more influence on 
> development directions and ensure that releases are packaged more 
> completely. Documentation and bug fix bounties could be sponsored as 
> well.
>
> Maybe what we need is _product_ management in addition to a release 
> management. If the EOB had some funds and more influence, it could 
> play that role. We need to set long-term development priorities to 
> make Evergreen a force in the market of the future and go beyond its' 
> reputation as a very basic system for small libraries.
>
> We've talked about using some crowd-sourcing software to gather 
> support for specific development and that is a good idea. The EOB 
> could throw some money into the crowd-sourced pot for specific 
> projects, if it had some.
>
> It seems that the common opinion is that we really don't need to 
> change much because things are going well as they are. While a lot of 
> great things are happening, I think we could do better with a little 
> more long-term strategic management of the Evergreen product. That 
> seems like the natural role of the EOB. Of course the EOB would always 
>  consult with the whole Evergreen community as it does this work.
>
> Stephen Elfstrand
>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/eg-oversight-board/attachments/20130815/4dd64665/attachment-0001.html>


More information about the eg-oversight-board mailing list