Hey everyone,
As I’m sure you’re aware given the title, we’ve decided to make the BeatBuddy Manager Open Source. This post will let you know what that means for you (both as a user of the software, and as a potential contributor to the project), and what our current development priorities are.
We’re Open Source
For starters, here’s a link to the repo: https://github.com/singularsound/openbbm.
As of this post, we are officially, publicly, open source. This doesn’t impact the current live production version yet, and there is currently no executable for the open source version. So as an end user you’ll only be able to:
- See greater transparency into the development of the manager
- Submit your own bugs for tracking and development
In the present you can download the code and compile the latest “on development” version. However, in the future you will be able to download and run a stable version (more on that in the development priorities section.)
If you are a developer and want to contribute to the project, the GitHub repo includes information on building and deploying the open source version of BBM.
New Dedicated Developer
With our recent expansion of the development team, the BeatBuddy is no longer sharing development man hours with other products and will have its own developer working full time on the project.
Meet Julissa (@julissadantes ). She will be and has been working full time on the Beatbuddy manager, and will help to ensure that the open source code is well maintained. We also have a quality-focused team member helping us ramp up our test suite, so we can prevent regressions and increase the quality of the project.
Our Development Priorities
Already, we have some tracked bugs in the repo which were carried over from the last testing session we did. As you’ll see in the repo, we’ve been steadily working on patching them, and bug fixes will continue to be a priority.
In addition to bug fixes we’re also pushing towards finishing AutoPilot functionality, and introducing automated tests. The automated tests will help ensure greater stability and fewer bugs in the future as well as speed up the development cycle both internally and for those contributing to the project.
Over time, the automated tests will gradually test more and more code. The build tools (what allows us to make the code an executable) have proven to be brittle for the purposes of introducing tests. We’re looking into that. In the meantime, we’ve an ever-growing body of manual tests which aims to be exhaustive and gradually automated.
After finalizing AutoPilot and creating the tests we plan to work on and release an executable, meaning it will be available for use by those not using development environments (end users).
Parting Words
Due to the peculiarities in the development process up until now, this version is somewhat disconnected from the publicly available BeatBuddy Manager. As such, some features, bugs, and workflows may be different than what you’ve seen before.
We look forward to working together on the future of the BeatBuddy Manager.
, but the sole fact that despite that I have been able to successfully build and run it shows that the code is well done and organized. Congrats 