LibreTime services (and other ways to sustain the project)

With the LibreTime collective set up, the maintainers could run a bounty program or provide a way for folks/orgs to sponsor features.

While paid services could also be offered on the collective, there seems to be consensus around keeping that separate. That said, it might be nice to compile a list of service providers (companies or individuals) that we could reference on the LibreTime website or wiki at some point.

If it sounds like a good idea, should folks just list out what they can provide in this discussion?

This article about CiviCRM may provide some inspiration and guidance with regards to how we can sustain the LibreTime project and a core team.

These are some of the CiviCRM sustainability initiatives:

  • Make It Happen (MIH) - campaigns to get or support new features that you’d like to see into the project but which hasn’t been included within core development
  • Support for bug fixes - funding priority bug fixes
  • Paid Issue Queue - letting people with the money jump the queue and get the fixes they needed into project
  • Hire the Core Team - to develop the features for your next project (providing that it was inline with our wider objectives).
  • Partner Program - for service providers that wanted to financially support the project
  • Member Program - for end users that wanted to do the same.

Aside from hiring the core team, we probably could run similar initiatives by leveraging the LibreTime collective and Open Collective API.

Curious to get some thoughts from the LibreTime team and other stakeholders. Would these types of initiatives work for this project?

This could be a tool for providing priority support for backers and sponsors https://github.com/marketplace/open-collective-bot

We could also enable a sponsor button on https://github.com/LibreTime/libretime linking out to the Open Collective and even a maintainers Patreon account
https://help.github.com/en/articles/displaying-a-sponsor-button-in-your-repository#displaying-a-sponsor-button-in-your-repository

In addition to sustainability initiatives provided by LibreTime, we could dust off and actually use Open Producer collective (hosted by Open Media Foundation, 501c3) to provide any of the above for LibreTime and other OSS projects in this space.

Please join #openproducer channel in Open Collective Slack if you’d like to collaborate or partner up!

Open Collective just relaunched their bounty program. This is the basic way it works -

  • Bounty contributors first comment on the issue they’re interested in, to ask a core contributor to assign them to it. This ensures that multiple people aren’t unknowingly working on the same bounty simultaneously, and gives our core team the chance to check everything’s in order.
  • Set a time limit based on the complexity of the issue, so that if an initial bounty contributor doesn’t deliver it can be opened up to others
  • Contributors must complete a simple issue before moving on to one more complex. This helps assess skill level and avoid frustration and lost time.
  • Complex issues don’t really work as bounties, because they usually require a lot of back and forth and are hard to scope accurately in advance. drop them in favor of larger issues split into small bounties.
  • Use a “bounty candidate” label so other team members could bring potential bounty issues to the attention of the core dev team and they could be assessed for suitability.
  • Make sure bounty issues are fully specced out and don’t require more design before starting implementation.

Bounty levels -

  • $100 for “minimal complexity issues” (<1 hour average estimated completion time)
  • $200 for “simple complexity issues” (~1 or 2 hours average estimated completion time)
  • $500 for “medium complexity issues” (~1 day average estimated completion time)

To facilitate this, they came up with the Contributor Ladder:

First Time Contributors

  • Have access to minimal or simple complexity issues
  • Contributors are not part of the Open Collective GitHub organization
  • Fork our projects on GitHub and push changes on their forks
  • Should comment on bounty issues to get assigned (limited to one at a time)

Contributors (at least 1 completed issue)

  • They get added to the Open Collective GitHub organization
  • Can assign themselves bounty issues (limited to one at a time)
  • Have access to minimal, simple or medium complexity issues

Recurring Contributors (3 or more completed issues)

  • Added to the “Recurring Contributors” group on the Open Collective GitHub organization
  • Can assign themselves bounty issues (limited to two at a time)
  • Have access to minimal, simple or medium complexity issues

Confirmed Contributors (3 completed issues including at least 2 with medium complexity)

  • Added to the “Confirmed Contributors” group on the Open Collective GitHub organization
  • Become candidates to work on complex issues or projects on a negotiable per-project or hourly rate

Could something like this work for LibreTime?

We’d obviously need a budget to provide bounties, but incorporating some of the sustainability initiatives listed above could provide a way to do that.

What does everybody think?

I’d be open to the idea but it would depend upon us having more $ flowing into our project than we have currently available. Most of the things we need to accomplish are on the higher complexity range and even small contributions can be tricky because the frameworks we are using are so outdated from the point of view of most web developers.

As mentioned here, I think all this would be in scope with the Open Collective sponsored initiative.

Sounds like you’re making a good case for setting a budget goal that would enable maintainers to spend more time on the project.

What if we incorporated similar sections for services, support, membership, etc. into Libretime.org? Think that would be the best way to funnel in users and contributors.

I think support would be a good one, as it doesn’t require us to front money - organisations pay the collective for support, the person who provides it issues the collective an invoice for the amount agreed between them and us.

The bug bounties would require us to have the funds to pay the developers for the issues, while eventually I would love to do that, we currently do not have the means to do so. Initially I think we should have a support tier where companies can pay a monthly donation and receive X number of hours a month in support. It would require probably 2 people to commit to being the support personnel (I’m happy to be one, but my PHP is lacking, so would be good to have someone who knows the PHP side of things). The project and the people providing support then agree on a hourly rate for that support, which is managed by the collective (the support members submit an invoice and get paid from the contributions made by the companies wanting support)

What about something like CiviCRM’s Paid Issue Queue where new features and bug fixes may be prioritized by providing direct financial support.

We’re already set up to create campaigns on LibreTime collective. LibreTime API could provide us with an opportunity to define our own process.

CiviCRM again provides some good source material for types of services and processes. Main decision here is whether or not LibreTime core team is interested or has the capacity to provide client-facing services. Similar to a LibreTime SaaS offering, this might be something core team members could collaborate on through a partner.

It would be great to have some sort of consensus from all maintainers about what LibreTime could provide through the website and collective.

If there are people with the time and expertise to commit to working on PHP bugs, then this could work.

That’s what I based my suggestion on. I would be willing, but it would be through my employer, as that is something we offer already, so they would invoice the collective for the support provided.

I think partners offering bespoke or hosted services would deal with clients/customers directly rather than using LibreTime collective as a conduit.

Campaigns for specific goals or features would provide stations and other stakeholders a way to influence the roadmap. I think we should circle back to recent discussions about development priorities and reassess what resources (time, skills, funds) are needed to accomplish.

Bumping over this bit of recent discussion on LibreTime Development Priorities

We should definitely determine a financial goal. I think it should be for all aspects of the project - development, PM, docs, marketing, community, fundraising, etc.

Following up on some of @robbt’s comments from Any interest in LibreTime available as a SaaS with hosting and support??

I think more users would pay for services or financially support the project if it was easier and more obvious to do that.

What if we followed through with building out Libretime.org?

I’m not sure we’d want or need to form an entity and hire staff. Funds for contributors (even full-time… just as long as they’re freelance) can already be routed through Open Source Collective 501©(6) fiscal sponsor via https://opencollective.com/libretime

Again many good marketing and branding ideas we could incorporate into a new LibreTime website. We can do this while keeping the OSS project separate by incorporating some of the models CiviCRM is using to sustain.

Should we create an issue and/or repo in https://github.com/LibreTime to work out the details?

Following up on some related discussion in LibreTime chat https://chat.libretime.org/libretime/pl/arjt8dmjtpyx7cd1frt7karpsy

From @robbt

Also had another question from a user as to whether I would implement certain features for pay, I said I’d rather things go through OpenCollective for transparency but we need to hash out how we can do a bug bounty type program where people dedicate money towards development of certain functionality and we split the money amongst the developers. Not sure if there is any sort of escrow type of thing where people can pledge money but aren’t charged until after the feature is completed. I’ll also open an issue for Github sponsor.

We can use Open Collective to do something similar to CiviCRM Make it Happen campaigns (one of the examples discussed in this post).

There’s a good bit in their detailed process we could incorporate to fund large pieces of needed functionality https://lab.civicrm.org/community/sustainability/-/wikis/Make-It-Happen

Similar to CiviCRM, we can already refund or reassign donations with Open Collective https://docs.opencollective.com/help/v/master/hosts/refunds

Another benefit of Open Collective is there are several ways to pool/allocate funds between projects and contributors.

I think the following would be good candidates for this type of campaign -

Because these projects already overlap we could probably have the same PM lead each campaign - also have the same people focus on marketing, fundraising, and other roles that are needed to make campaigns like this happen.

If OpenProducer coordinated these campaigns on it’s collective, those working directly on the projects (dev, docs, etc.) could invoice against that collective or funds could be transferred to LibreTime collecive.

We probably should hash out this process in Github, but we have all the ingredients to make it happen.

This page on the OBS site might provide some inspiration with regards to how Open Collective could be incorporated into the contribute or sponsor page.
https://obsproject.com/contribute

With a new libretime.org in the works, we should see if we could incorporate this and some of these ideas discussed in this thread.