Eemil Laine: Keeping up with upstream: maintaining open source plugins in a changing ecosystem

By: Eemil Laine, Software Developer, Mediamaisteri Oy

Transcript

1. Keeping up with upstream Maintaining open source plugins in a changing ecosystem Mindtrek 2026
2. Who am I Eemil Laine • Software Developer • 4.5 years at Mediamaisteri • MSc, Tampere University What I do • AI innovation & plugins • Designing AI workflows
3. 39 employees What we do 25 years of experience ✓ Maisteri LMS, our learning platform built on open source Moodle 1.5 million end users ✓ Learning design €4.6 million revenue ✓ Training and coaching An open source LMS provider
4. Our side of Moodle The plugins and branches we develop and maintain
5. What we keep alive almost 500 about 360 plugins our customer sites run branches of our plugins in use about 190 our own about 300 from others about 140 customer other branches Every time Moodle updates, all of these have to keep up. Installed by today’s production customer builds. Test, demo and dev copies and test branches are not counted.
6. What are Moodle plugins? Plugin = an add-on that extends Moodle Activity Theme Report Block Login Integration Moodle core Our own plugins Plugins from others we write and maintain them from the Moodle community: we install them and keep them working
7. What is a customer branch? Customer branch = a copy of a plugin, changed for one customer the plugin Why? Their own look Customer A logo, colours, layout A change only they need Customer B an extra field, a different report Quick to do no need to make it work for everyone
8. How did we get here? Twelve years of small, reasonable decisions
9. Our plugins and their customer branches Customer branches we maintain Own plugins we maintain 350 290 300 250 190 200 150 160 100 140 120 50 50 0 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026* Installed by production customer builds, state at the end of each year (* 2026 = today). Test copies and test branches are not counted. 2013-2018: from commits in our plugin repositories. Rounded to the nearest 10.
10. Upstream sets the pace and every plugin and branch has to keep up
11. How Moodle versions work 3.5 3.6 3.7 3.8 3.9 3.10 3.11 4.0 4.1 4.2 4.3 4.4 4.5 5.0 5.1 5.2 5.3 Releases LTS 3.5 bug fixes security fixes only LTS 3.9 extended LTS 4.1 LTS 4.5 4.5 security ends 4 Oct 2027 LTS 5.3 until 1 Oct 2029 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 Upstream decides the schedule. We decide only how well prepared we are.
12. Porting our plugins, every upgrade Started → half done Half → all done Moodle’s support for the old version ends half: 6 mo start: 1 mo 3.5 → 3.9 all done: 15 months 520 plugins and customer branches start: 4 mo half: 7 mo 3.9 → 4.1 all done: 12 months 330 plugins and customer branches half: 9 mo start: 4 mo 4.1 → 4.5 370 plugins and customer branches new version out all done: 15 months 6 months 1 year 18 months Every upgrade, porting our plugins filled the whole year Moodle gives.
13. What we learned from our three biggest problems
14. Don’t always build a custom plugin Problem 1 → lesson Before building a new plugin, try these first: A+B An open source plugin An existing plugin Two core plugins together A custom plugin someone already built it make it work for this problem too the same result only when nothing else works shared upkeep upkeep you already pay zero upkeep upkeep at every upgrade Every plugin you build is a plugin you port at every upgrade.
15. Example: reports Problem 1 → lesson A customer needs a new report. A dedicated report plugin Moodle custom reports we write it, test it and port it built into Moodle core, made in the browser upkeep at every upgrade no maintenance cost Moodle core can do the same reporting, without the maintenance cost.
16. Problem 2 → lesson Too many customer branches What we did What a setting could have done Change a label new branch Label text Hide one field new branch Show field Another colour new branch Colour One extra option new branch Extra option The smallest change got its own branch, and every branch had to keep up.
17. Problem 2 → lesson Fewer customer branches Customer branches we maintain Own plugins we maintain 350 290 300 250 200 150 160 140 100 50 0 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026* Installed by production customer builds, state at the end of each year (* 2026 = today). Test copies and test branches are not counted. 2013-2018: from commits in our plugin repositories. Rounded to the nearest 10.
18. The next upgrade went smoother Started → half done Half → all done Problem 2 → lesson Moodle’s support for the old version ends half: 6 mo start: 1 mo 3.5 → 3.9 all done: 15 months about 300 customer branches start: 4 mo half: 7 mo 3.9 → 4.1 all done: 12 months about 150 customer branches new version out 6 months 1 year 18 months Half the customer branches, done three months sooner.
19. Extend upstream, don’t copy it Problem 3 → lesson One login page, two ways: 373 lines 30 lines copied from Moodle core a small hook into core broke at every upgrade: 3.5, 3.9, 4.1 and 4.5 no compatibility fix from 3.5 to 4.5 yours to fix at every upgrade keeps working Copy upstream code, and every upstream change is yours to repeat.
20. Every shortcut that feels small today is paid for at every upgrade. Thank you! Questions? Eemil Laine · Mediamaisteri