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
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
(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
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,
== 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)!
-- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.