# LibreTime Development Priorities
**URL:** https://discourse.libretime.org/t/libretime-development-priorities/51
**Category:** Dev Talk
**Created:** [November 13, 2017, 2:22pm UTC](https://discourse.libretime.org/t/libretime-development-priorities/51 "2017-11-13T14:22:15Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@robbt](https://discourse.libretime.org/u/robbt)
#### Post date: [November 13, 2017, 2:22pm UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/1 "2017-11-13T14:22:15Z")
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 [LibreTime.org](http://LibreTime.org) 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 [https://github.com/LibreTime/libretime/issues/267](https://github.com/LibreTime/libretime/issues/267) 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 - [https://github.com/LibreTime/libretime/wiki/Smart-Block-development](https://github.com/LibreTime/libretime/wiki/Smart-Block-development) - 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.
---
### Author:  [@squiggleuk](https://discourse.libretime.org/u/squiggleuk)
#### Post date: [November 15, 2017, 8:51am UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/2 "2017-11-15T08:51:18Z")
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 🙂
---
### Author:  [@gusaus](https://discourse.libretime.org/u/gusaus)
#### Post date: [March 6, 2018, 7:36pm UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/3 "2018-03-06T19:36:08Z")
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?
---
### Author:  [@facundo](https://discourse.libretime.org/u/facundo)
#### Post date: [March 9, 2018, 11:50am UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/4 "2018-03-09T11:50:10Z")
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.
---
### Author:  [@robbt](https://discourse.libretime.org/u/robbt)
#### Post date: [March 13, 2018, 12:10am UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/5 "2018-03-13T00:10:57Z")
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 -[https://github.com/LibreTime/libretime/wiki/Automatic-Playlists,-Smartblocks-and-Podcasts](https://github.com/LibreTime/libretime/wiki/Automatic-Playlists,-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.
---
### Author:  [@gusaus](https://discourse.libretime.org/u/gusaus)
#### Post date: [July 25, 2018, 6:38am UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/6 "2018-07-25T06:38:35Z")
@robbt How has this evolved since you posted this? Is there a specific need for certain types of contributors?
---
### Author:  [@robbt](https://discourse.libretime.org/u/robbt)
#### Post date: [July 28, 2018, 3:26pm UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/7 "2018-07-28T15:26:45Z")
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.
---
### Author:  [@gusaus](https://discourse.libretime.org/u/gusaus)
#### Post date: [July 29, 2018, 2:30am UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/8 "2018-07-29T02:30:40Z")
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](https://discourse.libretime.org/t/opencollective-to-help-sustain-the-project-and-community/84)
3. Update the list of development priorities - would alpha 6 be the next milestone? [https://github.com/LibreTime/libretime/milestone/6](https://github.com/LibreTime/libretime/milestone/6)
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](https://discourse.libretime.org/t/public-roadmap-and-a-process-to-onboard-contributors/120)
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.
---
### Author:  [@robbt](https://discourse.libretime.org/u/robbt)
#### Post date: [July 31, 2018, 12:21pm UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/9 "2018-07-31T12:21:39Z")
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.
---
### Author:  [@gusaus](https://discourse.libretime.org/u/gusaus)
#### Post date: [August 1, 2018, 7:47am UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/10 "2018-08-01T07:47:07Z")
Quick clarification on some previous points
> [@gusaus](#):
>
> Accept the reality LibreTime is unsustainable as an all-volunteer project.
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. [LibreTime: A Fork of AirTime due to stalled development - Airtime Development Discussions on Sourcefabric Forum](https://forum.sourcefabric.org/discussion/18302/libretime-a-fork-of-airtime-due-to-stalled-development/p1)
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.
> [@robbt](#):
>
> 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…
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.
> [@robbt](#):
>
> …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.
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.
---
### Author:  [@gusaus](https://discourse.libretime.org/u/gusaus)
#### Post date: [October 11, 2019, 12:51am UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/11 "2019-10-11T00:51:20Z")
> [@gusaus](#):
>
> 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?
Bumping this up as we’ve had recent discussions in [https://chat.libretime.org/](https://chat.libretime.org/) on this topic.
There seems to be a consensus that @robbt @hairmare and @paddatrapper could use some help getting the [3.0 release](https://github.com/LibreTime/libretime/milestone/9) out the door (assuming that’s the priority). If we had a sense of the amount of time they’re able to commit (see above) we could then determine who/what we need.
We might be able to bring on and incentivize needed contributors by participating in Hacktoberfest (which [we’re already doing](https://github.com/LibreTime/libretime/issues?q=is%3Aopen+is%3Aissue+label%3Ahacktoberfest)) and the [Open Collective sponsored sustainer initiative](https://discourse.libretime.org/t/libretime-participation-in-hacktoberfest/387/12).
Considering the latter would be more of a collaboration and partnership, we’d have a good bit of room to experiment.
>
---
### Author:  [@robbt](https://discourse.libretime.org/u/robbt)
#### Post date: [October 11, 2019, 12:11pm UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/12 "2019-10-11T12:11:46Z")
If you know of any grants that we could apply for or people with deep pockets that want to give money to open-source projects with no return then raising funds might work. The challenge is that LibreTime as a free software project with AGPLv3 really has a steep hill to climb to be financially sustainable. Especially since we aren’t the original copyright holders of a lot of the code. So anyone who wants to use LibreTime is free to do so, which is the intent. Figuring out how to get the various people who are using it to donate and sustain the project seems like the most logical step vs. seeking outside funders.
I think the idea of a big fund putting money into opensource communication technology sounds cool.
As far as specifically getting the software into “beta” that is really just a semantic call and the fact that people are using the software in production already makes it more or less a beta. I’ve spent time triaging issues for what could be fixed to call ourselves beta. But most new contributions have been towards features that people want vs. digging through old code fixing bugs that mostly affect new users of the software.
---
### Author:  [@gusaus](https://discourse.libretime.org/u/gusaus)
#### Post date: [October 11, 2019, 8:08pm UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/13 "2019-10-11T20:08:44Z")
> [@robbt](#):
>
> If you know of any grants that we could apply for or people with deep pockets that want to give money to open-source projects with no return then raising funds might work.
I think the ideal would be to add grants to the [sustainer toolkit](https://discourse.libretime.org/t/libretime-services-and-other-ways-to-sustain-the-project/326) and make all of it part of the Open Collective sponsored sustainer initiative.
> [@robbt](#):
>
> Figuring out how to get the various people who are using it to donate and sustain the project seems like the most logical step
Creating perks and campaigns on [LibreTime - Open Collective](https://opencollective.com/libretime) could be a responsibility of the sustainers. OpenProducer would be part of the sustainer collaboration and also reaching out to potential participants [for this beta](https://discourse.libretime.org/t/any-interest-in-libretime-available-as-a-saas-with-hosting-and-support/121/12).
> [@gusaus](#):
>
> There seems to be a consensus that @robbt @hairmare and @paddatrapper could use some help getting the [3.0 release](https://github.com/LibreTime/libretime/milestone/9) out the door (assuming that’s the priority). If we had a sense of the amount of time they’re able to commit (see above) we could then determine who/what we need.
This is the main thing the LibreTime maintainers need to figure out. What will help you release 3.0.0 in a timely manner? Will funds enable you to spend more time? Would it help to have another maintainer involved? Ideally, how much combined time per week should be spent on LibreTime development.
I’d recommend a budget for one full-time developer (which could be split between maintainers and contributors) as a goal.
Coming up with the transparent process for allocating funds could be another thing led by the sustainer team.
Does that kinda make sense?
---
### Author:  [@robbt](https://discourse.libretime.org/u/robbt)
#### Post date: [October 11, 2019, 11:07pm UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/14 "2019-10-11T23:07:39Z")
So let’s budget approximately 75,000$ for a full time developer. That breaks down to 6,250$ a month. Let’s pretend every station using LibreTime paid 100$ a month towards development. That’s 62 stations we would need to agree to pay. 75k might be on the high side but it seems like a reasonable wage for someone with enough experience to do this and manage the project. We currently have 1 non profit donating 100 a month so we just need 61 more donors like that.
---
### Author:  [@gusaus](https://discourse.libretime.org/u/gusaus)
#### Post date: [October 14, 2019, 8:31pm UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/15 "2019-10-14T20:31:39Z")
> [@robbt](#):
>
> So let’s budget approximately 75,000$ for a full time developer
Seems like a reasonable ballpark. Let’s continue the discussion about how to meet that goal here - [LibreTime services (and other ways to sustain the project) - #7 by gusaus](https://discourse.libretime.org/t/libretime-services-and-other-ways-to-sustain-the-project/326/7)
---
### Author:  [@gusaus](https://discourse.libretime.org/u/gusaus)
#### Post date: [April 2, 2020, 6:42pm UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/16 "2020-04-02T18:42:25Z")
Cross-posting from a related issue - think a dedicated PM/scrum master would help?
>
>
> Basically there has been discussion at various place about when we can transitio…n LibreTime from alpha to beta. I think that we need to explicitly call out any show stopper bugs or missing functionality that would prevent us from transitioning to a beta vs. alpha release.
>
> Here is the list of bugs I've compiled and originally posted as comments below.
> \## Blocker issues for LT beta ##
> \- \[x\] #552 Automate silan fix during install
> \- \[\] #42 Line-in recording
> \- \[x\] #317 ensure locale works - in theory fixed by python 3 support
> \- \[x\] #129 autoplaylist depends on API calls to run
> \- \[x\] #461 issue with web player widget not working in certain browsers
> \- \[x\] #71 - either have an automatic upgrade path from airtime 2.5.1 + 2.5.2 or provide documentation for a tested approach that allows people to try the upgrade w/o data loss and report errors
> \- \[x\] #70 Watched Folders and/or CLI import
> \- \[x\] #550 Media monitor config
> \- \[x\] #577 ensure mediafolders/watched folders configuration doesn't break LT when upgrading to LT from AT
> \- \[x\] #580 we need to have a system that works with modern distros that use PHP 7.2
> \- \[x\] #376 - address all glaring issues in the docs where we refer to broken or non-existent features and ensure all introduced features have reasonable documentation
>
> \- \[x\] #624 Provide an easy installation process that is supported aside from the install script - this could be default docker containers or debian packages or both and explicitly define what distros we support out of the box and which ones are experimental and unsupported
> \- \[x\] #623 Provide a documented way of upgrading the software to the latest version
> \- \[x\] #190 Provide a well documented way to backup a LT instance
> \- \[x\] #951 Merge python3 support
>
> Since this is a subjective call we get to define the criteria. Up until now releases have been done at the discretion of @hairmare and they've been well documented and put together.
>
> When consulting the above list also look at the related \[beta 3 blocker project\](https://github.com/LibreTime/libretime/projects/2) (none are authoritative atm).
> Based on activity here and [in the forums](https://discourse.libretime.org/), it seems like more folks are using and interested in LibreTime. There may even be some additional folks with time to contribute.
>
> If one person (ideally not one of the core maintainers) could assume the PM/scrum master role, possibly we could coordinate some virtual sprints with the goal of 3.0.
>
> Thoughts?
---
### Author:  [@gusaus](https://discourse.libretime.org/u/gusaus)
#### Post date: [April 21, 2020, 8:40pm UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/17 "2020-04-21T20:40:50Z")
Cross-posting this discussion about [LibreTime 3 Beta Todos](https://discourse.libretime.org/t/libretime-3-beta-todos/529)
In addition to the above, would the other priority be a solid API?
> [@Planning out an API](https://discourse.libretime.org/t/planning-out-an-api/341/8):
>
> Cross-posting this comment from @paddatrapper [https://github.com/LibreTime/libretime/issues/935#issuecomment-571930675](https://github.com/LibreTime/libretime/issues/935#issuecomment-571930675) If we define a solid API, implement it in some framework and then work on replacing parts of the UI as we the functionality is developed, we probably will have more success. This also ensures that people can upgrade their instances without much risk. This is something I think we could use the OpenCollective for, even if we are only providing a small amount to a developer each …
---
### Author:  [@paddatrapper](https://discourse.libretime.org/u/paddatrapper)
#### Post date: [April 22, 2020, 10:00am UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/18 "2020-04-22T10:00:06Z")
> [@gusaus](#):
>
> In addition to the above, would the other priority be a solid API?
I don’t think it is for 3.0, but it will be important after that
---
### Author:  [@gusaus](https://discourse.libretime.org/u/gusaus)
#### Post date: [April 22, 2020, 6:16pm UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/19 "2020-04-22T18:16:42Z")
> [@paddatrapper](#):
>
> I don’t think it is for 3.0, but it will be important after that
Agreed the API isn’t part of a 3.0, but wasn’t sure if development was happening concurrently. Probably would make sense for all available/interested contributors to help get 3.0 out the door first?
> **[Issues · libretime/libretime](https://github.com/LibreTime/libretime/issues?q=is%3Aissue%2Bis%3Aopen%2Blabel%3A3.0-release-blocker)**
>
> LibreTime: Radio Broadcast & Automation Platform. Contribute to libretime/libretime development by creating an account on GitHub.
---
### Author:  [@paddatrapper](https://discourse.libretime.org/u/paddatrapper)
#### Post date: [April 22, 2020, 7:22pm UTC](https://discourse.libretime.org/t/libretime-development-priorities/51/20 "2020-04-22T19:22:43Z")
Development there has stalled a bit, as I haven’t had time to do anything. People are welcome to help, the PR is open, but I would suggest focussing on Python 3 port testing and 3.0 blockers first
[Next page](https://discourse.libretime.org/t/libretime-development-priorities/51.md?page=2)