Koha Versioning - Next

How does Koha stay relevant in a changing world?

Koha has been around for 20 years and continues to flourish. However, we should not sit back and not take note of what's happening in the world around us. We should strive to be the best we can be and continue to offer something for everyone.

Recent events

Acquisitions and mergers

There are acquisitions and mergers happening all around us. With businesses and resources being merged, we need to ensure we can continue to compete with innovation and strive for feature parity.

Folio

The Folio project has the might of Ebsco behind it and is a very well funded open source endeavour. It would be easy for us to lose out to them in the longer term if they can continue to innovate at a pace and attract new contributors using more modern technologies and practices.

Questions

• Reflect on the existing release cycle
  • Should we have a clearer set of goals with each release (a roadmap?)
  • Are we still able to innovate?
  • Are new features getting into community releases quickly enough?
  • Are new features getting into the community too quickly?
  • Is code quality of a high enough standard in all cases?
  • Are followup bugfixes and improvements to new features being done quickly enough?
  • In practice, when are upgrades taking place and what versions are people running (stable, oldstable or oldoldstable, monthly releases or static until next feature upgrade)

Identified strengths

• Stable and reliable mature product
• Predictable release pattern
• Tried and tested processes for
  • Development
  • Signoff and Quality Assurance
  • Translation
  • Documentation
  • Security practices
• Open and friendly community

Identified weaknesses

• Difficult to consistently fill all key team roles
• Difficult to attract experienced developers
• Difficult to attract new contributions
• Documentation generally lags a feature release behind
• New features can often take a very long time to reach main
• New features can often take a very long time to reach end users
• New features can often take a very long time to be adopted by end users
• New features are often added and then do not receive the polishing and maintenance they require.
• Bugs can go for a long time unanswered
• Use of outdated technologies without a clear route to adopting newer standards
• Significant technical debt
• Incomplete test suit
• Overlapping release notes are difficult to understand
• No way of highlighting new features outside of the release notes
• We lack a clear mission statement and coherent vision
• All work past the initial submission is voluntary and as such bottom priority for many

Proposals

• Encourage more mentoring and recognise those who are contributing in this way more widely
• Encourage more contribution in the Signoff and Quality Assurance space and reward 'good behaviour' more actively
• Make more use of the dashboard for both picking what to work on and rewarding work that has been done
• Publicise an agreed roadmap of area's we wish to concentrate upon over successive cycles
• Reward 'good community behaviour' more openly and obviously (SO, QA, Patch Rescue etc count as 'good behaviours')
• Introduce a two-track release process with LTS versions for the cautious and Rolling version for the adventurous?

Reality

• With the 22.05 release cycle an LTS version was added to the maintenance mix; However, a number of questions remain
  • How long should LTS be supported
  • What versions should be adopted as LTS
  • Should we drop support for some of the existing support branches rather than continue to maintain 'stable', 'oldstable', 'oldoldstable', '?oldoldoldstable?', '?lts?'