LibreTime Development Priorities

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

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? 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

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.

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.

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. LibreTime: A Fork of AirTime due to stalled development - Airtime Development Discussions on Sourcefabric Forum

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.

Bumping this up as we’ve had recent discussions in 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 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) and the Open Collective sponsored sustainer initiative.

Considering the latter would be more of a collaboration and partnership, we’d have a good bit of room to experiment.

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.

Does that kinda make sense?

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.

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

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.

Thoughts?

Cross-posting this discussion about LibreTime 3 Beta Todos

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

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

Understood - hopefully the WordPress based platform under development can provide a way to direct resources towards a 3.0 and an API.

This feature request can be a focal point for LibreTime / WordPress integration https://github.com/OpenProducer/openproducer-platform/issues/18

The FundOSS pilot should be considered a proof of concept for at least one way LibreTime could generate some budget to sustain. As a participant, a supporter/contributor to AzuraCast, and an active Open Collective community member, I can safely say this program is only getting started and it ‘should be’ a steady funding source for LibreTime.

At this point, I’d suggest attempting to integrate the IceCast2 SSL version into the mix. The project is one of the best I’ve run across and have been playing with it for a little while now, and with TLS (SSL) integration, it would at the least be a viable option for most of us. With security standards evolving so rapidly now, there needs to be some kind of movement towards full security standards throughout the package. That would be my humble suggestion at this point in any case. And THANK YOU for an amazing project!