As the year-end approaches, it's time to provide an overview of what our community has achieved over the past year. At the end of last year, I wished everybody a healthy and prosperous 2021. The year has turned out to be as challenging as the last and I hope this overview reaches you in a health as good as (or better than) last year's.
== Community interest ==
Although the number of hits on the website has declined steadily over the years, it seems that the decrease is slowing down: ca 1,000 fewer hits than in 2020, but 2020 lost ca 6,000 hits when compared to 2019. Traffic on the mailing lists was - in line with 2020 - very low this year. However, from the fact that during the year, we've also seen the number of Stars and Forks on GitHub slowly but steadily increase (Stars went up from 207 on 22 December 2020 to 260 today), we can conclude that there is still interest in the project, however, the broader community didn't have much time to engage with the project this year -- similar to what other volunteer-driven projects are experiencing this year.
== Releases ==
With the release of 1.9.0 on 25 September 2021, we realized our goal to release 1.9 in the second half of the year, around a year after 1.8. This way, our target of releasing around the middle of the year, in order for the software to mature well before year-end (when most companies close their books). Despite the short release cycle, we were able to include a sizeable list of new functionalities, changes and (code) cleanups through 902 files changed, 306,496 added lines and 271,066 removed lines of code (and comments) between 1.8.0 and 1.9.0.
With the number of releases doubled in 2020 over 2019 (44 releases over ~20 before), the question was whether we'd keep it up to release that often. Turns out we were able to meet our prior year standards with 38 releases in 2021:
1.6 (5): 1.6.29 - 1.6.33 1.7 (12): 1.7.26 - 1.7.37 1.8 (15): 1.8.10 - 1.8.24 1.9 (6): 1.9.0 - 1.9.5
Which excludes the alpha, beta and release candidate releases.
== Packaging and installation ==
For the 1.9 Docker images, we moved from Debian Buster to Debian Bullseye as the base operating system. Contrary to prior experience - moving to Buster - there were no notable problems in the move.
Significant engineering effort went into automating the mapping of Perl dependencies to their Debian package names during the Docker build process. By having this automation in place, error margin and manual release maintenance has been eliminated. The automation worked so well that it was backported from the initial 1.9 implemenetation to the release processes for 1.8 and 1.7 as well.
With some help from the Debian community, we were able to fix the packages that come with Debian Bullseye: the packages that were there before were missing the "old/lib/" subdirectory. Unfortunately, Debian still includes 1.6.
== Development progress ==
This year saw fewer commits than last year. Although this could be an indication that our project is suffering from the same problem many other Open Source projects have during the pandemic: a loss of available time from their contributors. I don't think that's the case for our project as some of it can be explained by the tougher topics being picked up in the second half of the year. Although the sheer number of commits was lower, the number of pull requests (832) is in the same order of magnitude as those from last year. The number of active developers - judging by accepted commits - went up from 47 last year to 9 people contributing commits this year - even though 2 of last year's contributors were one-off contributions.
Last year I expressed my desire to close a number of long-standing issues this year and in fact, we have:
* #975: Edit/Update on a saved invoice or transaction clobbers changes * #1135: Ability to delete a login account * #816: Ability to install in a schema other than "public" * #835: Performance of the balance sheet report (should use cached balances)
All from 2015, just to name a few.
Project commits on all branches (excluding merges and bots): 895 Erik Huelsmann* 139 Yves Lavoie* 61 Aung Zaw Win* 11 Neil Tiffin* 4 Richard T. Weeks 3 NoGare 2 lianto.ruyang 2 daOrangePeeler 1 Xin Wang * includes contributions on maintenance branches
By comparison, these are the figures for 2020: 1247 Erik Huelsmann* 179 Yves Lavoie* 108 Nick Prater* 37 Aung Zaw Win* 3 Håvard Sørli 1 Bobberty 1 Andreas Karlsson
Please note that the number of commits is in no way a measure of time spent on the project. Also note that these numbers don't include the time spent by those taking the effort to report their problems and taking the time to respond to developer questions as well as helping to test solutions when developers think they solved the problem. Similarly, there was a lot of activity with respect to issues:
Number of open issues at 2021-01-01: 226 of which remain open today: 137
Issues closed: 173 of which created before 2021-01-01: 89
Issues created: 105 of which still open: 21
Number of open issues today: 158
This amount of development activity triggers many CI/CD jobs. Last year, we had just moved our regular CI loads to GitHub Actions; this year we have run almost 2,000 CI workflows on the main repository alone(!). A high number of jobs was triggered by Dependabot and Renovate Bot, two bots which have helped us to keep our JavaScript dependencies up to date. While Dependabot could run integration checks multiple times a day, we moved to Renovate in order to be able to reduce the number of CI jobs and merges. They're now set to once a week -- we're not releasing multiple times per day from our repository anyway.
In the Changelog for 1.10 (https://github.com/ledgersmb/LedgerSMB/blob/master/Changelog#L3), you'll be able to read where we spent our time, for all effort that didn't end up in 1.9 and wasn't listed above. Areas that we're currently spending time on, include:
Encapsulating Dojo widgets in "custom elements" in order more easily switch component libraries Putting the requirements in place in order to develop our UI with Vue3 Development of webservice APIs
The 158 issues that are open today summarize into these statistics:
* 11 bite-sized: a good place to start when looking to make contributions * 69 enhancement: requesting new features added to the application * 4 help wanted: looking for someone to help out on this issue * 10 migration: these issues need help testing and developing migration from SQL Ledger * 6 needs-documentation: there's not enough documentation...
(Note that an issue may fall into more than one category or none at all.)
== New functionality and improvements ==
Distributed with 1.10, a very nice although somewhat niche, functionality was added supporting localized handling of taxes: in the US, Washington State (WA) operates a web service which serves the tax rate in the tax district. We have built a module that queries this service based on the billing address on the invoice. The module calculates the applicable tax amount and posts it. The webservice returns a "tax district code" which gets posted with the amount for tracking and auditing by an accountant. This use-case goes to show what customizations are becoming possible after the years LedgerSMB has been in development, with all the code cleanup that has been going on.
== Looking forward to 2022 ==
In 2022, we'll likely release 1.10 around the middle of the year; again in a release cycle a bit shorter than a year. This year two release branches will reach End-Of-Life status: 1.8 on 4 September 2022 and 1.7 on 4 October 2022. By the end of 2022, we'll be back to supporting two active release branches as we were before we switched to yearly release cycles. Experience has shown that given sufficient automation, maintenance of 3 branches is doable, but still challenging; there are simply too many merge conflicts on any non-trivial backport to do the job well.
And last but not least, I'm hoping for 1 or 2 new contributors (not necessarily developers; translators, testers, documentation writers or UI artists are all greatly appreciated!). If you want to contribute, but don't know where to start, please contact me.
== In closing ==
Thanks to everybody who contributed to any of the above in any way, especially to
Computerisms.ca for hosting our DNS Freelock.com for hosting our website and mailing lists Efficito.com for hosting our mailing list archive, apt repository, release and download server GitHub.com, CircleCI and coveralls.io for hosting our development workflow
My special personal thanks go to my GitHub Sponsors for supporting me for time, efforts and (financial) resources dedicated to the project!
Leaves me only to wish everybody in our community - and their loved ones - happy holidays and a safe and productive 2022!
Hello everybody!
I have been working on bringing LedgerSMB into OpenBSD. There are a variety of people wanting that, so this isn't just for me.
This past year brought me some financial problems (not a big surprise). I had to give up my server that was running the required -current releases needed for porting. This happened very quickly, so I managed to save most or all of my work onto an ugly Github repository. I found a great Black Friday promo, so I am now up and running again for much cheaper on the same server type with the same comnpany.
Porting just means collecting the correct Makefiles, patches and some short description information. Testing *within* the OpenBSD testing framework is required. This work is then submitted, reviewed and then committed to the ports tree.
--------------------------- If anyone is interested in having LedgerSMB running on OpenBSD, please let me know either on or off-list. --------------------------- If anyone is interested in helping out, OpenBSD runs great on just an external USB drive/stick. No need to cause any problems with your existing system. Except for LedgerSMB itself, just a bunch of Perl dependencies need to be brought in. Most of those are very easy to do. A few are harder like PGObject-* which also need testing with PostgreSQL.
I'll be starting a new Github repository for this work. The old mess can be helpful as a reference to avoid repeating work I finished.
participants (2)
-
Chris Bennett
-
Erik Huelsmann