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 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 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 - 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.
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?
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?
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.
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.
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.
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?
Determine people (developer, project manager, documentation, etc.) and budget needed to complete the next milestone in a timely manner.
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.
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.
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.
There seems to be a consensus that @robbt@hairmare and @paddatrapper could use some help getting the 3.0 release 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.
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.
I think the ideal would be to add grants to the sustainer toolkit and make all of it part of the Open Collective sponsored sustainer initiative.
Creating perks and campaigns on LibreTime - Open Collective 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.
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.
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.
Cross-posting from a related issue - think a dedicated PM/scrum master would help?
Based on activity here and in the forums, 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.
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?
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
