OSSVIAB - Exploring Open Source Viability Project

Roadmap:Next Beta release comes next week, includes:Bugfixes:

•         Cleanup deleted asset.uri’s
•         Avoid characetr conversion errors
•         Restore password reset button in patron editor

Behind scenes bugfixes

•         EG schema
•         OpenILS perl modules installable by Module:build
•         Default import scripts
•         import/export script improvements at command line

SVF – PostGres 9.0+ is required to upgrade to the beta…also includes Serials improvements – see changelog , amongst which are an improved caption / pattern wizardCirculation Enhancements

• in d/b grace intervals
• Circ matchpoint fallthrough
• Hold triggered recalls
• SIP2 now returns patron inactive /  expiry date

Cataloguing enhancements

• Authorities exposed by SRU/Z39.50
• Indexing improvements
• Multi-homes items
• Monograph parts
• Unified volume / copy wizard
• Call number affixes
• Safer searching
• NACO normalize overhaul

Performance enhancements

• New search performance tuning options (Cover density algorithm adjustments)
• Parallel fine generator
• Parallele hold targetter

Staff client improvements

• Self update
• Automated builds
• Firefox extended version
• Dynamic hot-keys
• Configurable patron registration elements / element annotation
• Client permission checks to show / hide menu items
• Staff client landing page ‘moar prettier’
• Unsaved data warnings

Feature roadmap 2.2 for forthcoming major release includes:

• Template / toolkit OPAC (with community involvement / assistance)
• Authority control sets (define your own authority controlled fields)
• Vandelay grows up (boolean matching, import failure tracking / reporting, match quality ranking)

Release Schedules

• Next 2.0 = now (next week)
• Next 2.1 = next week (beta 1)
• Next 2.2 release = beta in sept, full release in October (hopefully)

..and the goal is to move to time-based releases (still very much in process)Improvements to Processes

• Launchpad working well for tracking bugs & new features
• Moving to git
• Volume, complexity & diversity of patches increasing
• post 2.0 bugs less in number & severity than in 1.6
• Conifer sponsored security audit of 2.0.4 EG
• interim report showing pleasant lack of serious vulnerabilities, some minor fixes resulting               from this gone into 2.0.6
• Automated testing intro
• Approx 20 bi-weekly developer meetings have taken place..and continuing - notes, agendas etc.. all shared with community.
• ..huge increase in significant & also good quality community contributions to EG, which is very pleasing to see, shows growing maturity of contributor base

Credits esp for Ben Shum, Anoop Atre, DIG & wiki contributors, Chris Sharp @ Pines, UPEI, Pines, etc..etc..Evergreen 2012 will be 25th-28th April 2012 in Indianapolis..planning has already started

As appears pretty customary at this type of event now, there was a session set aside for 10 minute talks from a wide variety of presenters.

These went by too quickly & covered such a wide range of topics it’s almost impossible to make a coherent report on this.

Instead I’ll just refer readers to my typwithme notes for this session, and add a couple of brief personal highlights:

• Some nice improved features on MARC editing on their way shortly (courtesy of Bill Erikson’s talk)
•  Complete feature list of Evergreen under development (via Lori Ayre of Galecia Group)
• Natural Resources Library Canada doing some nice work with Evergreen / geospacial search linking
• FulfILLment project looks really interesting develoment (via Mike Rylander)

Session delivered by Galen Charlton of Equinox

There are 2 main EDI standards… EDIFACT and X12…Evergreen supports EDIFACT.. but X12 support is up for contributions

UN/EDIFACT

..this is not library based standard, we are just a part of user base in libraries

EDItEUR – not contemplating price quotation requests as yet (personal note - compliance here will be needed in Europe??)

Current support is for ORDERS, INVOIC, ORDRSP

INVOIC in final testing for KCLS,

ORDRSP slightly behind that in final tweaking, and has beentested with main public library vendors in USA..though not many others as yet. Galen requested people to let the community know as & when theytest successfully with other vendors

Setting up for EDI..requires following to be running on server:

• edi_fetcher.pl
• edi_pusher.pl
• action_trigger_runner.pl
• A/T template
• edi_translator

So orders activated are not sent by EDI immediately..instead, they are batched up & sent via cron job processes.  Thes processes then poll & waits for response messages

Setting up EDI needs

• Vendor Records
• SANs
• EDI Profiles
• Shipping messages around

the effect of implementing EDI is on Orders workflows, and very minimal for end user as, if a vendor has an EDI profile in the system, then when an order is activated, automated processes kick in.

Workflows responses:

• Order responses
• Update statuses
• Invoices
• Create invoices - You still have to approve them yourself

Coming soon:·

• Enriched orders e.g. addition of info into the orders message·
• More testing, more partners· better user interface - not particularly user friendly design as yet
• Documentation!

Q&A:

• Workflow is predicated on order being generated within EG..if starting from Vendor site, then there is an additional process to load them & create order records, at which point you kick off the EDI
• Can have multipee consortia libraries have different EDI profiles with same vendor? Yes, but need multiple copies of vendor account to do so (apply single EDI profile to each one)

Delivered by Chris Sharp of PINES

PINES are on Evergreen at start of year 5 with the system, so have a great deal of experience and have learned the lessons very well.Background:

• Pines came about in 1999 as many Georgia libs were on non Y2K compliant systems…and the idea of a state wide library card was also germinating at same time
• As the system expanded, which started as early as 2001, they began having issues with not coping with volume of transactions on existing proprietary vendor system..got worse as got larger.
• As their LMS contract was also up for renewal at same time as these issues arose, and they made the decision to build their own OSS LMS rather than go for various non-suitable Proprietary systems. Brad LeJeunesse, then GPLS sys admin, was instrumental in this move.
• Various structural requirements eventually led to Pines being required to hand over system management to a 3rd party agent, and Brad moved out of GPLS to form Equinox Software, who provide 3rd party support services - this was a period of a lot of uncertainty & change

Coming through this, the growth of PINES really started again really in 2008

Chris honestly points out that at that point Pines was a little bit of a mess - the system was stable, but the software itself was still really in huge development phase…they had helpdesk software, but no really procedure for how best to manage the processes to utilise that effectively..thus GPLS re-organised and introduced a triage system & more structured approach to providing support.

Governance: Pines membership has following setup:·

• PINES member libs meet annually
• Governed by contractual agreement with PINES entity
• Each of 52 director’s has a vote on issues set before the membership
• Executive committee of 9 directors, elected annually, serving 3 year terms
• GPLS staff co-ordinate & enforce policy issues· GPLS co-ordinate documentation plus RFP’s, bids etc,, on behalf of PINES libraries, which are fed out to Equinox & others

They have to have good communication channels for consortium to work, so·

• Have listservs for various areas
• GPLS forums· GPLS Helpdesk - they try to drive all traffic to this
•  ..but personal emails / calls will be answered as last resort
• GPLS keep all documentation & policy info up to date & co-ordinated

they also keep PINES archival documents, and provide

• a Training role offering Circ, Reports, Cataloguing, Local Sys Admin..
• this is pretty ad-hoc at moment, would like to formalise it better
• they are also interested in providing more online training

PINES Development Process·

• PINES library staff request a feature
• GPLS work with staff to define properly & create a requirements document
• Development is then queued based on importance / date created
• GPLS provide all system administration
• PINES system administrator staff position
• Contract with Equinox software on support· also work with GPLS IT staff

The Future of PINES?

This is very much planned around expansion and resilience:

• Plan to move from current server cage to larger one
• Re-architecting the cluster
• Anticipate more growth

Q.&As·

• Feature requests - if one effects staff of end user consistency, then GPLS put the request to executive committee for final  decision
• Feature development requests tracked within software..spreadsheet with details on timelines etc.. shared with all staff for transparency
• Helpdesk - not provided 24/7, but do provide on call service over weekends plus automated alerts of helpdesk tickets that come in
• PINES policies over-ride local ones, but there is flexibility & policies can be changed via Exec Committee

Personal notes - another really useful session, with a lot to be taken on board for any library looking at a potential consotrial implementation, not just of Evergreen, but any LMS really

Delivered by Megan Dudek & Evette Atkin of MCLS

MCLS decided to go down the OSS route after er proprietary vendors failed to provide any kind of good consortial offer for a replacement LMS.

They have taken a light governance approach, which looks like:

A Director’s Group - to resolve any issues that working groups cannot resolve and give strategic direction.  This meets 2-4 times per annum

Cataloguing, Opac / Circulation & Development groups, meeting a couple of times per year which are made up of people the groups themselves invite and staff nominated by Directors.  These meet at similar times to Directors group, and also collaborate outside the meetings using tools like Google Docs, the Wiki etc..

They stated that there was some confusion over co-ordination early on over group membership, remits etc.. but this has settled down now.

To help with co-ordination and managing the consortia, they have produced the Michigan Evergreen wiki, which looks good, and they also provide a number of listservsStructure & lessons learned:

• Each library has own instance of OPAC, so can look how each one wants
• They have have had a great sense of community build up from the working groups
• The Libraries have a formal legal contract with MCLS to covers things like policy adherence..but not everyone complies nevertheless, and this has caused some small scale issues (personal note - back to the importance of a solid governance structure & rile set here - important for the UK)
• Collaboration - this has happened at thehigher levels of the consortium, but they would like to encourage more of this to amongst frontline staff..though tye recognise that there is not as yet a mechanism really for this to happen in anything more than ad-hoc manner
• Empowerment - MCLS want libraries to feel they can take control & help themselves more - they’d like to see member libraries take more ‘ownership’ within the system
• MCLS assign permissions to do cataloguing processes based on training courses attended.

Personal thoughts & notes:

• Each lib has own EG instance..I wonder if this means you lose consistency on policies, user experience etc… more resource heavy & config complex too?  Need to do some testing on this.
• MCLS operates kind of like a 3rd party not for profit organisation that co-ordinates things.. this might be a way fwd in UK
• I am not sure the fairly relaxed governance structures talked about here in USA would work in UK..possibly a more formal setup likely to be needed, especailly around things like SLAs, exit strategies, funding guarantees, maybe policy issues.

Delivered by Rogan Hamby (SC LENDS), Shasta Brewer (York)

This session was very much about About how the two organisations have changed their culture by utilising Open Source Software (OSS), and about how OSS allows self determination.

SCLends went from the initial idea to having all sites live on Evergreen in 2 years – the initial gathering took place on 19/11/08, and their first  go-live on 28/5/09 (that’s a very rapid development and implementation timeline!)..they had a  high variance amongst member libraries in terms of size, operations etc.. which really adds to that incredible timeline achievement.

Early development relied very much on individual expertise because of this, and they admit to still struggling to replace this model with one based on institutional knowledge, which is critical to long term stability..so the model is very much one of distributed labour & very sparse infrastructure.

The State library has been the organiser, but not policy driver within the partnership - this was felt to be a fairer & more flexible arrangement than a possibly quite authoritative model. (something to bear in mind when looking at Governance issues for any potential UK consortia)

They have found that operating without traditional vendor presents a new paradigm..and it takes some culture shift.  For example, it took while to comprehend what operating in a shared environment really meant for each member and from a management point of view (again, an issue that will have relevance for any new UK consortia that adopt this model)

Their Governance structuresare as follows:

• 1 lib system means 1 vote
• Advisory group = 1 director & 1 vote from each ember library
• Help Desk = 3 staff at state library
• Level 1 support incumbent on SCLENDS libraries themselves

Operating without traditional vendor presents a new paradigm.. takes some culture shiftTook while to comprehend what operating in a shared environment really meantGovernance structures= 1 lib system means 1 voteAdvisory group = 1 director & 1 vote from each ember libraryHelp Desk = 3 staff at state library - these services funded within State library budgetLevel 1 support incumbent on SCLENDS libraries themselves

c20% of problems only get passed up to Equinox as an external contractor.

State library manages·

• Contracts
• Finance (e.g. levy on member libraries, which equates to approx half of what they each used to pay to vendors)
• Helpdesk
• Project management·
• Communication
• Volunteer working groups on:· Systems· Cataloguing· Circulation· Training

Their relationship with Equinox is interesting..they do some work a traditional vendor would do, but SCLENDS increasingly are doing many of the turnkey vendor tasks themselves..thopugh this has been very much an ongoing learning experience

For SCLends, this experience has really raised the bar in terms of meeting expectations e.g. in need to understand the LMS to a great depth of knowledge, to provision of & support to networks, WAN links etc.. and the question is, where does the move towards becoming the vendor yourself get drawn?

There seems to be a very interesting crossover over of traditional sys admin role / vendor role / new stuff coming out of the SCLends experience

From their experience SCLends have come to the conclusion that while distributed labour is good, centralised management of a project and system of this scale is critical to ongoing stability & development

A very apposite session to attend given the UK situation, and relative lack of experience with larger consortia, and the governance / support issues that are incumbent with it.

Delivered by Grace Dunbar (Equinox) and Matt Carlson (King County Library System)

This was very much an ‘idiots guide to project managing system development’, with lots of lessons learned, do’s and don’ts, which I’ll briefly note here:

Lessons

• Get a test server installed
• Do a GAP analysis - refer to roadmap for what is coming to future releases
• Check what GAPS may be workflow dependant..do you really need to plug the gaps?
• Then prioritize..major vs minor gaps..major dev vs tweaks etc..worth while to get an outside opinion on your workflows too… do they make sense?  can you lose any ’sacred cows’ you can get rid of?

And once you have identified required development..what’s the way forward?

Well…If you don’t have resource in house, then you need to contract out, so

First thing is write a scope of work – you will need full requirements including

a) Use Cases

b) Single function

c) Specificity

..and remember to design for 95% of use..don’t get too sucked in to focussing on the exception cases as this can be an unproductive sink hole of time & resource

Once you have scope of work.. next to find a development service, so:

1) Engage the wider community

2) go visit the Evergreen conference & fact find / make connections

3) Look around locally

4) Write an RFP

5) Hire a consultant

(personal note - I’m not sure how many of those options are open to Uk libraries right now, especially locally, or on the consultant basis)

**do all this well in advance!!** ..proper prep prevents poor performance!

Next comes the contract:

Need specificity in

a) Hours estimates

b) Costs - not to exceed £xx (maybe build in a buffer here?)

c) Training & documentation required (this is often overlooked imho)

d) specify if you want dev’t code to be put back to community & licence to release under

Need schedule of work with

a) Deliverables

b) Milestones

c) Testing - allow plenty of time here..be realistic in how long this takes..and think on how you will test

d) Sign off Invoicing - when, how, what’s expected pattern

So, looking at this from both client & developer side, firstly, What  is client thinking throughout this?

Challenges:

1) Communication

2) Scope creep

3) Realistic time for testing, feedback etc..

Best Practices

1) Maintain clear project plan - this may be a moving target

2) ID you experts & use them!

3) Provide real examples & case studies for dev’s to work from..never too soon to plan for go-live timeline & identify the dependencies!

and what is service provider thinking?

Challenges:

1) Multiple clients & projects competing for time ..build in ‘buffer time’, don’t waste time with un-needed meetings etc..

2) Communication ..keep lines clear & don’t have ‘too many cooks’ - keep all on same page

3) Use cases - clarity!

Best Practices:

1) Hve 1-to-1 project managers = avoids communication problems

2) Clear & shared objectives

3) Set priorities

and when you are both are ‘in the thick of it’:

1) Stay focussed

2) Go for ‘good enough’..not necessarily perfect

3) Resist function creep

4) Look 3 weeks ahead

5) No plan survives initial contact with real life

6) Be a shark - keep moving forward on things

amd remember, test will not equal production, so

1) Create a test manual - ensure you have consistency in what & how you test

2) Edge cases will appear - stay on target, and don’t get dirstacted by these

3) Engage staff and patrons in finding solutions - helps build engagement amongst your key stakeholders

4) You *will* need a test server!!  Just do it!

and, don’t forget training!..Remember:

1) Managers not necessarily good trainers

2) Set aside mandatory training time

3) Get structured feedback

4) Plan for ongoing training

FInallym on to the last stage of Implementation:

a) try to phase in changes

b) Have a fall back position

c) Data migration needs

d) Change is tough!

e) Pat yourself on the back - and your staff too

and some Don’ts

:1) try & replicate your old LMS in Evergreen

2) think adding work does not impact timeline

3) overestimate time committment

4) Forget to engage staff & users

5) Muddy the water

6) Freak out

..finishing up with some Do’s

1) have 1 point of contact on each side

2) Give lots of detail

3) Listen

4) Plan for 25% buffer on timeline

5) Stay positive

6) Keep everyone in the loop

7) Have fun

Have a life outside of project

..a nice informative session that could be applied to any development project, not just an Evergreen one.  I suspect lists like these should be pinned to every project manager’s wall, as it’s so easy to overlook some of these points when engrossed within a project itself

Delivered by Steve Callender (ESI), Suzannah Lipscomb (ESI)

Reporting functionality is a very powerful tool in Evergreen, but perhaps the one that causes the most questions and queries when people try to use it - hence it’s an area that does need a lot of thought & training.

Firstly, the reporting function can be found in Admin > Local Admin > Reports in the system

This area contains templates, reports & output..these are bsic building blocks for creating reports.  Users can have their own reports folder, or share with other staff, and the initial job is to set up your own folders. This is quite straightforward - you create your own folders, choose whether to share or not, and can detail who to share with down to a very specific level.  You can also share to consortial, library or local level

There is no need to worry if you make a mistake when creating folders - you can edit name, permissions etc.. delete, hide, clone, move templates around etc.. the system is very, very customisable & flexible.

Next step after creating folder is to create a template.  Do NOT just dive right in..think about what info is needed in the output, as this will function as a guide as to what data sources will need to be to draged in. To clarify this, ‘Sources’ are the main data tables information. e,g, ‘Item’ .’Field Name’ = attributes bringing in e.g. ‘Barcode’. (Personal note - I suspect this becomes far more intuitive as you get used to the terminology - there’s a definite staff training issue to be aware of here!)

Also, a user needs to know the structure of the data..e.g. what info is held where..so initially may have to do quite a bit of fishing until they get used to the structure in which Evergreen stores information.Filter represent.a way of pre-sieving the data into format required,  and although on initial view they seem quite complex, this becomes a more transparent function to use when one knows the Evergreen data structures & terminology used.

On a personal note - I  don’t think this is any more ‘user unfriendly’ than products I’ve used myself in proprietary systems (e.g. I use Voyager web reporter, and this has very similar feel to it) ..with exception of Director’s Station form SirsiDynix, which is actually 3rd party developed’ - it would be excellent if someone could adapt a 3rd party reporting tool to Evergreen at some point, I also think there would be good value in creating & sharing a set of ‘pre-canned’ reports, especially for very UK specific requirements e.g. common reporting such as CIPFA, PLS, Sconul etc..

Moving back to the session, there is an ‘Export to excel’ option as well..so you can pull your basic data out & then do more complex work outside of Evergreen.Steve & Susannah pointed out some example community documentation on how to create a report and pointed out that sharing knowledge in this way is a good way to overcome the issue people seem to be having on a wider scale..they also highlighted the importance of making good documentation for more complex activities such as reporting.

Couple of things that occurred to me during this session were:

1) This could trip UK people up..if you have to know the terminology very well that’s a barrier, and of course there is some divergence between terms used in the UK vs the USA e.g. LMS vs ILS which could complicate the issue.  But these barriers could be overcome with familiarisation & training.

2) I suspect there’s a good scope for messing up a report & creating something that could loop & hog system resources..so implementers of Evergreen might want to build a reporting server into infrastructure (maybe as part of resilience strategy?) and mainly encourage reporting to be run against that.. This is a strategy I have seen used a lot in many proprietary implementations.

Overall, a good, if brain stretching, session to kick off Day 3 with!

The 2 part session was delivered by Anoop Atre (PALS) and Eli Neiburger (Ann Arbor)

Anoop kicked off a session I had a lot of interest in, being as we are already using VuFind at Swansea University (and with our SWWHEP partners) in conjunction with our current ‘Voyager’ LMS, and have found it to be an excellent product.

I’m not going to document the nice features of VuFind again here - there’s a lot of material already in our SWWHEPSRCH blogon that, but Anoop ran through them for the benefit of of everyone present. Suffice to say, it’s an impressive feature list.

Anoop then covered the challenges PALS had faced when linking VuFind to Evergreen. VuFind requires a driver back to the LMS to support live availability info in holdings data, and that work is underway to provide full connectivity driver for Evergreen with VuFind - the current one does not quite do it all yet.

Anoop mentioned that the driver is very dependant on the stability of database schema, soif that changes e.g. for dev’t, then driver needs rewriting.  There is work now underway to see if it is possible to write a php / OpenSrf version of the driver instead which will more robust to underlying database changes, and thus a more resilient long term option.

The 2nd part of the session came from Next, Eli Neiburger of Ann Arbor Disctrict Library (AADL) and covered use of SOPAC  with Evergreen.  His slides are available here

AADL have committed to continuing to use SOPAC when they migrate to Evergreen as their LMS (note, I didn’t get a date for when this is planned, but got impression it would be in near future), and have done a lot of work to make the change in underlying LMS invisible to the end user when the switchover takes place.  Eli feels this is actually pretty close to being achieved even now.

Eli, after going into quite a bit of technical detail on how SOPAC works, and how this has been achieved, went on the detail what he sees as their future developmental possibilities, which include:

• ‘The Stub LMS’..  Evergreen will just have basic bib data in it, rest will be held outside in other applications best suited to each set of data e.g. in SOPAC - a real ‘distributed system’
• Development of better bibliographic &  information aggregator / cataloguing tools for SOPAC
• Patron created stubs- version controlled bib records
• Transaction data in catalogue so users can see their borrowing history & have that inform their future choices.

AADL have also done a deal with an online Creative Commons music distributor, and added music downloads to catalog.. this looks really great, and cost per use working out as less than 50c per download.

This session was delivered by Mark McIntyre of the eiNetwork, and Kathy Lussier of MassLNC

Background: eiNetwork provides a total solution (Network, pcs, single shared LMS) to a public library network with 45 patners covering over 75 sites

In looking for a replacement LMS (ILS in US parlance), eiNetwork identified a real gap between the aims the libraries had, and those aims espoused by the vendors offering proprietary solutions.  Coupling this with cost issues, they felt this meant they should take a serious look at Open Source alternatives , leading them to Evergreen.

Mark felt that it’s the ecology bit where open source systems either flourish or founder, and that there are huge opportunities with open source to grow a local resource to feed into that.  Among his ideas of benefits of growing this local resource were:

• …the opportunity to be part of a large & growing community
• ..the reduced reliance on single vendor..improved funding opportunities if they can use local resources
• .. local funding to boost local economy & create local jobs

Mark went on to say they looked at ways they could grow this sort of ecology for the eiNetwork, and outlined the following ideas:·

Collaboration with 2 major universities that study & research OSS·

• ..which had led to tech startups & incubator spinoffs in those Universities·
• Identification of student internship & project opportunities e.g. Google Summer of Code·
• Identification of local user groups with cross interest e.g Postgres, Unix·
• Making ongoing local contacts

This investigation work led them further - they contacted Equinox  to set up a test server to have a good look at Evergreen, and dug far deeper into the relevant blogs, IRC logs, mailing lists etc..From this research, they were able to identify both priority gaps for their required functionality, and actually document a process for bringing local resources to bear & up to speed for development & support of Evergreen.

Key things that they had learned so far were:·

• A good base of research on what makes OSS communities work·
• Lots of stuff on governance structures - (N.B.) this is key stuff for UK to explore as I think it’s a current weak area.  I do intend following this up & asking Mark if he’s anything he can share with a wider audience on this·
• The importance on getting the documentation right & available.. and Evergreen community has made significant improvements here recently·
• Universities as potential source for development (again, this could be very relevant to UK thinking, and an attractive proposition in particular if one were to look at cross-sectoral collaboration)

Kathy Lussier ran the 2nd part of the session, and talked about the MassLNC project - 3 existing consortia coming together & collaborating on Evergreen .

They looked at what their required enhancements would be, and used the process as an opportunity to evaluate their own processes as used in libraries and to throw away things that no longer fitted.. (this is another key point to me - we can’t afford to have ’sacred cows’ in this area - libraries & services change over time, and processes should match that - where they don’t, throw them out..you’ll soon accumulate ‘new’ sacred cows anyway!)

After a fairly intensive ‘grading’ process for functional enhancement requirements, MassLNC then  slpit them up and offered specific pieces of development work out as smaller individual contracts rather than doing one ‘big’ procurement for the lot (an approach I liked - spreads cost and risk, and helps grow a larger development base to work with in future)

MassLNC did this work in consultation with the main Evergreen Development group (to keep enhancements in-track with overall Development roadmap), and feel it worked well.  The only ‘problem’ area they found was that  as yet, Evergreen doesn’t have a significantly large development base, so the contracts ended up being quite concentrated among a small group of companies (a problem I know we would face in the UK also..but one I suspect will fade over time as & when Evergreen becomes more established on these shores - nevertheless, a point to be well aware of)

Kathy rounded things up & mentioned that they’d also done some work with ‘development partnerships’ (i.e.with other Evergreen users who had similar requirements for development) They found this a good way to share & reduce costs and share expertise etc..  (final note for me on this session - the idea of ‘development partnerships’ I see as an excellent one and a real strength of open source)