LedgerSMB
The foundation for your business
Fork me on GitHub
[ledgersmb-devel] LedgerSMB community overview 2020
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ledgersmb-devel] LedgerSMB community overview 2020



Hi,


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 2020. The year has turned out to be a big challenge and I hope this overview reaches you in a health as good as (or better than) last year's.

Where many open source communities seem to have been negatively affected by the circumstances this year, core project seems to have held up very well and actually done better than last year.

== Community interest ==

Although the number of hits on the website has declined steadily over the years, we're seeing the bounce rate decline (steadily) as well, in combination with an increase in the average time spent on the site and the average number of actions on the site. It seems our site increases in relevance to the visitors which we are getting. In prior years I wrote how a decrease in website traffic might not be an indication of loss of interest as more and more users are converting to mobile web-experiences.
Traffic on the mailing lists was also very low this year. 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 158 in February to 207 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 -- as other volunteer-driven projects are experiencing this year.

== Releases ==

With the release of 1.8.0  on 4 September 4 2020, we realized our goal to release 1.8 in the second half of the year, around a year after 1.7. We were even able to reduce the release cycle below 1 year! 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 786 files changed, 149056 added lines and 153741 removed lines of code (and comments) between 1.7.0 and 1.8.0.

This year we released almost double the number of releases as we did in 2019 and 2018: where we delivered around 20 releases in both prior years, this year we delivered:
  1.6 (11): 1.6.18 - 1.6.28
  1.7 (19): 1.7.7 - 1.7.25
  1.8 (14): 1.8.0-rc1 1.8.0 - 1.8.8 (including pre-releases: 1.8.0-alpha1 1.8.0-beta1 - 1.8.0-beta3)
44 releases!

== Packaging and installation ==

With the 1.8 release, we were able to move the Docker images to Debian Buster! Moving the Docker image to Buster in 2019 with the 1.7 release was unsuccessful due to dropped support for ssmtp in Debian and lack for replacement functionality and lack of support for some of the ssmtp functionality in LedgerSMB itself. In 1.8, we added extensive support for the configuration of outgoing e-mail to LedgerSMB, allowing for this transition.

The Debian ledgersmb package for 1.6 transitioned to Buster last year and we were very happy about that, but at the same time we found breakage in the package. We hoped to fix that soon after discovery. That turned out quite differently: as it happens, we had to come to the conclusion that we lost contact with Robert James Clay (aka Jame) with last known contact around October 2019. He used to maintain the Debian packages for us, including many of our dependencies which hadn't been packaged for Debian before. Unfortunately, LedgerSMB 1.6 has now been dropped from  Debian Testing due to problems with dependencies and no newer versions have been packaged. We hope that Jame is doing fine and in the mean time would welcome anybody who wants to take over (Debian) packaging.

== Development progress ==

This year we had a lot of development activity as demonstrated by the size of the 1.8.0 release and the number of patch releases for our active maintenance branches. The number of active developers - judging by accepted commits - went up from 4 last year to 7 people contributing commits this year, generating some 800 pull requests on GitHub:

Project commits on all branches (excluding merges):
   1247 Erik Huelsmann*
    179 Yves Lavoie*
    108 Nick Prater*
     37 Aung Zaw Win*
      3 Håvard Sørli
      1 Bobberty
      1 Andreas Karlsson
* includes contributions on maintenance branches

By comparison, these are the figures for 2019:
    640 Erik Huelsmann
     26 Yves Lavoie
     21 Nick Prater
      1 David Godfrey

Please note that these numbers don't include the time spent by those taking the effort to report their problems with the software 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 2020-01-01: 339
    of which remain open today: 180

  Issues closed since 2020-01-01: 278
    of which created before 2020-01-01: 159

  Issues created since 2020-01-01: 161
    of which still open: 42

  Number of open issues today: 222

This amount of development activity triggers many CI/CD jobs. Last year, we had just moved our coverage testing loads from TravisCI to CircleCI due to the fact that our coverage testing loads were taking too long to complete within the TravisCI limits. This year, unfortunately, we're moving our regular CI/CD loads from TravisCI to GitHub Actions: TravisCI has seriously restricted (effectively dropped) support for Open Source work loads. Even though we now have effectively moved off TravisCI, I'd like to take the opportunity to publicly thank them for all the builds that they were able to donate to this project over the course of years: our project ran almost 10.200 builds and my own account ran roughly 5.700 additional builds in preparation for merges! TravisCI, thank you!
With everything going on, we were able to improve our test coverage to 44% (from 41 last year), but unfortunately, that's not nearly as much as in the year before (34 -> 41).

In the Changelog for 1.9 (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.8 and wasn't listed above. Areas that we're currently spending time on, include:

 * Selection of a new translation engine which supports more than 2 plural forms
 * Gradual polishing of 1.8 through regular fixes of issues left to be polished after 1.8.0 release
 * A Perl and PostgreSQL API to form a foundation to build a Web API and command line application on
 * Improvements in our _javascript_ handling to support a switch to Vue

The 222 issues that are open today summarize into these statistics:

 * 15 bite-sized: a good place to start when looking to make contributions
 * 33 needs-design: waiting in our design queue to be handled
 * 125 enhancement: requesting new features added to the application
 * 12 waiting-for-user: can't proceed on these without further reporter input

(Note that an issue may fall into more than one category or none at all.)

== New functionality and improvements ==

In 1.9, _javascript_ code will be built with Webpack: the standard for _javascript_ delivery. This allows us to add static code analysis as well as lots of code transforms customary in the _javascript_ world. Basically it makes our _javascript_ delivery more "as any JS project would do it". Yves sank immense amounts of time into trying to realize this change, wrestled and came out a winner! Thanks Yves.
Another change that isn't highly visible, but should be noticeable is that we worked on improving the page response times. We were able to eliminate a lot of overhead (in miliseconds) from our page generation.

Another topic that we spent a lot of time on is the consistency and validity of the example Charts of Accounts delivered with LedgerSMB: by changing the storage format from SQL code to XML structured data and formulating consistency rules for the XML data set, we were able to establish consistency and resolve consistency issues. Through this effort new users trying other Charts of Accounts than the US or CA charts that the developers usually use, should have a much better first user impression.

== Looking forward to 2021 ==

In 2021, we'll likely release 1.9 around the middle of the year; again in a release cycle a bit shorter than a year. Fortunately at 10 June 2021, 1.6 will reach end-of-life which means that over the first half of the year, supported maintenance branches will be 1.8-1.7-1.6 while over the second half of the year it will be 1.9-1.8-1.7. Experience this year has shown that while maintaining 3 branches is challenging (especially with the rate of change we're currently going through), it is doable. However, running more than 3 maintenance branches in parallel won't be manageable. This is one of the reasons why we decided that the 1.8 and later branches receive 2 years instead of 3 years community maintenance support. Another reason being that upgrades have become a lot less painful over the past years (or so our users have told us).

For 2021, I hope that the project can resolve a series of long-standing open issues as well as finally completing (and expanding on) the foundation for APIs at every level of the application: database, Perl, Web and (command line) application. Next to that, I hope that we can significantly increase our test coverage just like last year (and unlike this one) as well as cleaning (removing) old/deprecated code. All of that obviously in the expectation that it will result in an attractive 1.9 release!

And last but not least, I'm hoping for 1 or 2 new contributors (not necessarily developers; translators, testers, documenters or UI artists are all greatly appreciated!). If you want to contribute, but don't know where to start, please contact me.


Thanks to everybody who contributed to any of the above in any way, especially to
* those who offered me or one of the other developers private access to their data to help get their problems resolved. This way, we were able to resolve a series of COGS related corner cases which I would not have been able to reproduce -- saving me huge amounts of time.
* 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, TravisCI, 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 highly improved (over 2020) 2021!


--
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
_______________________________________________
devel mailing list -- ..hidden..
To unsubscribe send an email to ..hidden..