Ed Veal, ByWater Solutions
Switching from Proprietary software to Open Source Software
Differences
- Administrative
- Mind set
- Development
- Resources
Front line staff don’t care as much about the switch; still have to learn new system. Get support from the same sources on staff.
Biggest difference? The community behind a a piece of open source software. Bug reported; community fixes; community pushes new releases. Things get developed because members of the community want things to be developed, funded, etc. The community drives, instead of the business plan; there is no business plan behind Koha. Proprietary focus on what business can sell.
Koha — open source — together because of community.
Question – if a lot of IT staff are Windows/proprietary supporters, and the staff who supports open source leave an organization and things go wrong, how do you keep open source packages in place?Â
Need a plan to put together those transitions.
Concern of someone about to move to Koha: current cost for library is only Sirsi hosting [but LOTS of money goes to that];Â will it require more staff time and talented staff? 1) If you go your own way, you can self-host — have to have knowledge, resources. 2) Can choose support company vendor to support, hosting, do migration. There are ways around this more easily.
Another library moving from III to Koha, biggest issue, cultural shift from proprietary to open source, switch in nomenclature — really an ILS issue, not open source. The cultural change is in administration; by using an open source product, especially one like Koha that is so community-focused, that’s where the transition will have to happen. Koha grows as you, the community, wants it to go.
Community to rely on for answers to questions. IRC channel; listservs; bugzilla.
Frontline staff at a library on Koha for awhile, they now ask if things can be done differently. They raise issues and make suggestions.
No matter what change/development you make to a system, someone has to sit behind a keyboard and write the code. Whoever is writing the code, developers whether they be in-house for a self-hosted library or through your support company, there are costs in doing that. That’s where the development costs come from. There is a shift from paying from software licensing to helping make the software better.
A lot of people are paying for the flashy, big developments but there are behind the scenes developments that are also needed.
Development process in Koha: someone finds a bug, wants an enhancement, report is placed on the community Bugzilla site. A developer (someone who writes code) writes a patch. Once that’s written, it’s added to Bugzilla. Community starts testing, it’s signed off on. Then it goes off to the Quality Assurance (QA) folks, who do a second layer of testing. Then the Release Manager (RM) checks it again, and decides if it’s going into master/next release. Everyone in the Koha community is volunteering to test.
One good way to give back to the community? Start testing patches in Bugzilla. The nos are more important than the yeses. Anyone can sign off on a patch; QA folks are checking other parts of Koha as well, to make sure it didn’t break anything; RM is checking to see if patch works; checking to make sure it doesn’t break Koha in other places and meticulously checks the code.
Need more Americans on Signoffs/QA team, especially QA team. Can volunteer to be on QA team. Say, “I would like to help.” And people want to help you!