Here's my continuing the tradition to write about the state of the project on each year end.

== Community interest ==

With the growth of the number of places to obtain LedgerSMB, it's becoming increasingly more difficult to estimate the project popularity. We're now available through at least the following channels: Distribution packages (Debian repository, Ubuntu ppa, our own Debian/Ubuntu repository), Docker images on Docker Hub (with docker-compose support), regular 'tar file' download through GitHub or our own download site. Many of these sources
don't track stats for hits, or at least those stats aren't available to us. A notable fact though is that the Google and Yahoo searches 'open source accounting' serve as the top hits a number of pages which cite or refer to LedgerSMB.

Based on the steady stream of issues being logged on our GitHub issue tracker, the fact that the number of forks and stars (as well as watches) are steadily growing and the number of Docker Hub downloads is steadily increasing, I'd say that we get a fair amount of attention and our community is continuing to find people interested.

== Releases ==

Last year's community overview looked forward to 2018 and expressed the hope to release LedgerSMB 1.6 in the first half of the year. And we did: June 10th we released 1.6.0 -- little less than a 18 months after 1.5.0! As expected, we were able to further shorten the time between releases.

This year, we haven't topped last year's 20 releases. With 20 releases, the year can definitely be called succesfull though. We released:

• 10 stable releases: 1.6.0 - 1.6.9
• 10 old-stable releases: 1.5.15 - 1.5.24

Releases hardly ever contain fixes for regressions anymore. That's to say, regressions for functionality that worked in a recent release. Regressions being fixed went back to functionality being broken before 1.5.0 and sometimes even during the 1.3 or earlier release cycles(!).

In addition to the 18 releases, significant new infrastructure landed on the master branch which helps advance the project to higher levels. An excerpt of all the work done includes further extension of the testing framework, separation of the template frameworks for UI and 'printed' materials and lots of minor and major code cleanups. In addition to generating releases, each year some effort is spent on release engineering; this year, we further automated the release announcements by automatically posting the news updates on github.com and ledgersmb.org (using the same announcement text as is used for the mail announcements).

== Packaging and installation ==

The Debian+Ubuntu packages now include a new 'ledgersmb-1.6' package. The packaging process keeps improving, because by the end of the year, new packages were announced within 24 hours after the release of the new LedgerSMB version.

With the introduction of the LedgerSMB 1.6 Docker builds, further energy was spent in shrinking the images. We started the year with images around 250MB in size (reported by Docker Hub); by the end of this year, images for 1.6 are showing less than 180MB and those for 1.5 around 160MB in size. That's another significant reduction.

== Development progress ==

Over the course of 2018, 107 issues were created, of which 35 remain open at the end of the year (of which 8 enhancements); 126 issues were closed. More than 470 pull requests were created and 479 were closed. These numbers are significantly lower than last year, which is probably due to lower development activity (especially in the master branch) over the course of the second half year. However, the general feeling is that we are also continuing the trend of last year: due to the fact that the code base is increasingly more stable, there's more time to work on the more involved projects: those that (prepare to) refactor
the code base. This work, while necessary, doesn't immediately produce commits or PRs.

Last year, we set aside the code that we want to part with in the source tree, signalling to (potential) contributors which parts need improvement and which need replacement. Consensus has it that this distinction has lowered the barrier of entry by offering a relatively clean code base to newbee developers and this has in fact been a reason for this some of the activity of this year's contributors.

In 2018, we ran over 1250 builds (starting at 6091; currently at 7354 and counting), but more importantly, we increased our test coverage from 27.48% to a current coverage of 34.22% (thanks Travis CI for all the donated compute time and Coveralls for the stats and analysis interface!). While we definitely have more code to cover to get to an acceptable coverage level, this is a very welcome increase!

Areas which received extensive attention beyond that which has already been published through the 1.6 release notes include:

• work to explore the benefits of moving our code base to Dancer2
• work to identify the roadmap to merging the MC (multi-currency) branch, including work to
  • re-implementing some of the changes on the branch to adopt new paradigms as on 'master'
  • implement checks, balances and tools to help people migrate their data to MC on upgrade
• work to de-couple frontend and backend implementations, even before there is a web API
• work to explore what needs to be done to support a REST API

== New functionality and improvements ==

This year we added relatively little truely new functionality to the code base. Most effort was spent improving it. One thing worth mentioning in this area is the fact that we added tests to assert that modules (at the very least those we intend to keep) comply with a minimum level of documentation -- we set the documentation standard through Perl::Critic rules and we'll work toward increasing the standard over the next year, most likely.

== Looking forward to 2019 ==

Ideally, we'll see the 1.7 release in the first half of 2019: that would shorten our release cycle to the much-desired yearly interval. Releasing by the end of the first half year puts businesses in a good position to test the software before running the year-end figures (assuming most businesses do so by the end of the calendar year).

This year will likely be the year to land the MC branch effort on master, too. A lot of work has gone into preparation for this step and more work - following a precise checklist - is under way. Wether this functionality lands before 1.7 or after, is yet to be decided. Stability comes before anything else and we don't want to break our upward trend in that area. (Although some instability is to be expected after a subject this big lands on master, I'd like to have it stabilized before release.)

For 2019, I wish the project finds one or two new contributors and our community has the patience to wait for MC to land before we continue into (also) highly desired areas such as a REST API -- to help the project to focus, that is.

Then, lastly, let me finish by wishing everybody in our community a very good 2019 and by stressing that we'll welcome everybody who wants to contribute to our efforts (be it in development, testing, translating, documenting, coaching or sponsoring)!