LibreTime Development Priorities


So this post is mainly a braindump on my part to figure out where I should dedicate my energy when it comes to LibreTime.

Other people are welcome to chime in. Here are the parts of the code that I’ve been thinking could use some focus.

  • Installation Issues
    We have a couple of bugs related to the installer and no clearly defined way to easily change the default passwords etc. for LibreTime during or after the install. There is also the additional thought of creating unofficial debian packages for Ubuntu and Debian to accompany the unoffical rpm for CentOS. The idea of getting an official debian package is held up by the requirement that we need to have each of the javascript libraries included separately (but ours have been customized in weird ways).

  • Documenting and Refining AutoPlaylist UI
    This is another thing that has been long on my todo list. Basically the AutoPlaylist function works but there is no in-line hints as to how it should work, how to use it etc. And there is no documentation on about how it works etc. In addition we never customized the calendar view to give any indicator that a show has been set-up for AutoPlaylist vs. left ignored and completely unscheduled.

  • Testing, Refactoring and Code Documentation
    The codebase is largely untested and we have a lot of jQuery code that works but isn’t formally tested. I ran into this when coding the addition to the Smartblock for relative playlists. I’m thinking that looking at Selenium and figuring out how to run tests on the web interface itself might be a worthwhile investment of time just to provide a better means of testing tricky code. Also although we do have some tests setup we don’t really have integration testing configured and I’m not even sure how we could do that exactly. The LibreTime environment is a hodgepodge of code crafted in haste by a variety of devs, almost none of whom are around on the project anymore (or never were considering they worked on Airtime at SourceFabric). This creates a lot of technical debt and means that very few people understand the code. Applying some sort of rigid documentation standard where we identify each function and what it is used for might be useful but I suspect it would eat up too much of our limited time. This is why I left alone after posting it. Also it create a huge copy of my codebase and doubled the size of my repo for uncertain benefits.

  • Code Library Cleanup and Code Upgrades
    Going along with the previous topic. We also a large amount of javascript libraries and python libraries that we depend upon. The javascript libraries are for the most part manually installed and in one way or another have corefiles hacked to make them work how the original developers thought it made sense. Getting a list of these and then rewriting the code so that they don’t need to be modified (or else forking them) is a requirement for getting an official LibreTime debian package. Also we should figure out which libraries we are going to use and possibly rewrite the whole UI to use a new library after we’ve sorted out this mess. For instance the Podcast code is all written with Angular because a new dev was hired on and angular made more sense than jquery but I don’t think we want to rewrite the rest of the app to use Angular and there are still bugs in that code that we haven’t fully fixed.

  • Documenting the API and seperating front-end from back-end.
    Although LibreTime is written with the ZendPhp MVC, there have been a lot of different means through which it was developed. There is a API client that runs via Python and connects to the Zend PHP API. But not everything is clearly implemented and the API is not well documented. If and when we rewrite the codebase it would be very helpful to have this all well defined so that we could for instance rewrite the front-end but still have it work with a solid backend API. Sorting this out and determining what connects to what seems like a necessary step to untangle the various parts.

So yeah, that is my overview of where we are at currently. I didn’t mention the smartblock stuff which I documented on this wiki page - - Smartblocks have the benefit of a feature that people are already using and a number of requests have been made to improve them. Whereas most of the stuff I mentioned here is bigger picture stuff that would hopefully make these smaller incremental changes less costly to develop. Feedback from anyone else is welcome as to where they think we should prioritize.

OpenCollective to help sustain the project and community

Hi Robbt,

I suspect that documenting and refining the autoplaylist ui would be very beneficial to prioritize - It was added as it was clearly the most asked for feature by libretime and upstream users! Enhancing the UI a little and updating the docs would certainly make things clearer for new users and users moving to us from upstream - It will also save everyone time having to explain to the people!! I did also see some other issues raised relating to jingle/ident insertation into smartblocks every x items, which I feel would be very beneficial to many users, although that’s not in the list above - would be a great feature to have for those wanting to run a completely automated station!

Installation - While it’s not ideal, it does work. I’ve managed from both milestone/release tarballs and also via git. There’s a fair bit of work been done on this, so maybe it’s in an ok-ish state for now.

Other code/refactoring/front-back-separation and other tech debt - My coding skills are limited, but I’m wondering if we had a cleaner simple, comments, documented, etc, codebase, it might make it easier for others to start contributing and give us more momentum - Maybe this work would help us work around the javascript blockers that are causing issues with deb/rpm packages?

Hope my ramblings help in some kind of way :slight_smile:


Is there a public roadmap and a process defined for how to contribute, request features, or sponsor development?

Is there a need for people to help develop, maintain, and manage the project? If so, is there a specific place we should be directing and onboarding contributors?

Public roadmap and a process to onboard contributors

I want to offer myself to write the documentation of AutoPlaylist. Right now, I’m using Centova as SaaS, and really want to switch to Libretime.

The problem is, that after hours of reading and searching, I can’t seem to understand exactly how AutoPlaylists work. I have no issue on reading forums threads and coming up with a “how to” guide, but I just don’t find enough info. I am not a developer, although I did study some coding at the Uni. If you can point me to any valuable resource on this topic, I’ll be willing to collaborate.

Edit: should add that I do have an instance of Libretime installed and running, just for testing proporses.


Your help would be welcome, sorry for the delay in responding. I haven’t been focusing the majority of my time on LibreTime at the moment. I wrote some basic documentation on the Github Wiki here -,-Smartblocks-and-Podcasts

The long and short of it, if you have an automatic playlist setup for a show, LT will schedule the playlist around one hour before the show airs. This is currently triggered by accessing the web interface or by the airtime-playout so if you have a number of hours of shows playing without triggering this it may not trigger the automatic playlist. This is a bug that needs to be resolved, but only affects people that have dead air on their station or shows that last multiple hours.

Let me know if you have any other questions.


@robbt How has this evolved since you posted this? Is there a specific need for certain types of contributors?


Honestly there has been no development. I think @hairmare is very busy with other things and I have been focusing my energy on other aspects of my life. The biggest challenge for me is that I have limited free time to sit down in front of a computer and program due to my personal life and being a stay-at-home dad while my wife does research. It might make sense to setup something like zulipchat (open-source alternative to slack) or even an IRC channel on freenode and try to get people together for a meeting but I am not sure I have the additional bandwidth to accomplish that or even participate fully at this juncture or how easy it would be to coordinate a time when we’d have enough of a developer consensus to make it work. I’m open to suggestions.


My recommendation would be to move forward with some of the suggestions scattered about these forum posts…

  1. Accept the reality LibreTime is unsustainable as an all-volunteer project.
  2. Create an OpenCollective to help sustain the project and community
  3. Update the list of development priorities - would alpha 6 be the next milestone?
  4. Get a realistic sense of availability from @robbt & @hairmare. What is the average amount of hours/mo you’re able to commit without a budget? What is the average amount of hours/mo you’d be able to commit with a budget?
  5. Determine people (developer, project manager, documentation, etc.) and budget needed to complete the next milestone in a timely manner.
  6. Consider posting a Public roadmap and a process to onboard contributors

I’d like to help with onboarding, outreach, and looking for ways to sustain ongoing development once there’s a realistic plan to move foward.

Any interest in LibreTime available as a SaaS with hosting and support?

Well the issue here is, sustainability simply means that the product continues to exist. As more and more people are finding and using it I don’t think we can say it is unsustainable. It is unclear as to whether a paid project would be sustainable because that would require a certain amount of consistent funding over a long period of time. If we were to go forward with creating an OpenCollective it is unclear where the donations to fund it would come from as LibreTime is a niche product and it is primarily used by broadcasters with limited budgets.

I appreciate the enthusiasm but I don’t think @hairmare has much available time as he already I believe has a full-time job and my ability to focus on the project is rather limited as well for the immediate future.

So without dismissing this entirely I think that we should test the water so to speak and without coming up with a grand plan to build a paid development team a next step would be to setup a process for taking donations and distributing them to developers who are contributing and can use the funds. OpenCollective could be a way to pursue this. I also have a 501c3 non-profit I am involved in that could help facilitate some of this.

OpenCollective to help sustain the project and community

Quick clarification on some previous points

This was more of general view on any large scale, user facing product. Offhand I can’t think of any that are actively developed, documented, and maintained long term as a 100% volunteer project.

For LibreTime, a continuously updated and maintained version of AirTime broadcasters can depend on, seemed to be one of the main motivations for the fork.

Main reason I was suggesting 3 - 6 was to get some sort of sense for what and who might be needed to achieve those goals.

I had to go back and check these comments… I’m certainly not proposing a grand plan to fund a full-time development team. Agreed that’s unrealistic.

Maybe I should have referenced that Open Collective discussion last. Seems like we agree how it can be used. Especially if we have a pretty good sense of development priorities, needs, and goals.

OpenCollective to help sustain the project and community