[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Funding Debian projects with money from Freexian's LTS service


as you probably know, my company — Freexian — has been running the
commercial side of the Debian LTS project, collecting money from sponsors
and dispatching it to contributors handling the security updates. This is
working pretty well by now and the amount of funding is sufficient to
cover the workload.

This led me to think about expanding a bit the scope of the LTS funding
that Freexian is managing to answer two different needs that I identified:

1/ First, the LTS work necessarily had an impact on other Debian teams
that made the project possible (security team, DSA, buildd, ftpmasters,
debian-www mainly) and I wanted to be able to give back to those teams.

2/ we have always allowed paid contributors to go beyond just preparing
security updates for the LTS release. They can pick tasks that improve
the LTS project at large (we try to collect such tasks here:
https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues) but they
should not go over 25% of their allocated monthly hours so this limits
their ability to tackle bigger projects and we would like to be able to
tackle bigger projects that can have a meaningful impact on the LTS
project and/or Debian in general.

So I thought about it and I made a proposal to the paid LTS contributors
that has been accepted: every month we are putting 10% of the LTS funding
aside to be able to fund larger tasks/projects. We will regularly seek
project proposals, review them and pay someone to implement the proposals
that have been retained.

We have tried to formalize a process for this in this salsa project:
(I'm pasting a copy of the two relevant markdown files at the end)

We highly encourage the above-mentionned Debian teams to make proposals.

A member of those teams can implement the project and be paid for it. Or they
can decide to let someone else implement it (we expect some of the paid
LTS contributors to be willing to implement such projects), and just play
the reviewer role driving the person doing the work in the right

Contrary to Google's Summer of code and other similar projects, we put
the focus on the results (and not in recruiting new volunteers), so we
expect to work with experienced persons to implement the project. But
if the reviewer is happy to be a mentor and spend more time, then
it's OK for us too. The reviewer is not a paid position.

I really want to try out something on this level but I also know that
the topic is sensible so I want to get your feedback to make sure
we find a good balance and make it acceptable to Debian at large
(I'm not aiming at 100% acceptance, but I'd like this to be accepted
just like LTS funding has become normal for most Debian developers).

So I welcome your comments on this proposal. I'm really busy lately so I
might not be super-reactive but I have postponed this discussion for too
long already so I'm sending it out anyway (at this point we already have
13200 EUR that we can use to fund projects!).


PS: Here are the relevant files from the project-funding git repository:


:warning: This document is currently in draft state.  Is subject to
frequent and significant revisions until it is finalized.

# Project Funding

This repository is used to track free software projects that Freexian is
willing to fund to some extent.

Freexian can fund projects for different reasons and the rules applied
in each case will vary depending on the origin of the funding:

* As part of its Debian LTS offering, Freexian has a budget to invest
  into projects that will directly or indirectly improve the Debian
  LTS project. Any Debian member can submit project proposals and they
  will all be considered. See [LTS-specific rules](Rules-LTS.md).

* Freexian can also put out projects proposals on its own. In that case,
  they are usually justified by internal needs or customer requests.
  See [Freexian-specific rules](Rules-Internal.md).
# Project Workflow

Each project progresses through several stages.  In order to ensure complete
high quality work on fully vetted projects, a project must be proposed,
approved, executed, and completed.

## Vocabulary

* Project submitter: the person or team that submits a project proposal
* Executor: the person who "executes" or "implements" the project, it's
  the person whose work will be funded by Freexian
* Reviewer: the person who ensures that the executor completed the project
  and that the result is compliant to the project description.
* Bid: an offer made by someone to execute a project at a given price
  following a given timeline
* Project Managers: person(s) appointed by Freexian to handle issues and
  merge requests in this GitLab project. Usually Raphaël Hertzog.
* Freexian manager: Raphaël Hertzog

## Project Proposal

The project development process begins with the completion of a project proposal
and submission of the proposal.

A sample project proposal template and associated instructions for completing
the sections of the project proposal can be found in the _templates/_
sub-directory.  Once the proposal has been prepared and is ready for review, it
should be submitted as a merge request against this project.

It is usually expected that the project submitter also picks the role of
either the reviewer or the executor. When acting as executor, the project
proposal should come with a bid. When acting as reviewer, they should
ideally be ready to review the bids to select the best one.

### Proposal Naming Convention

Projects (and their associated proposals) are identified using the following

> YYYY-MM-short-name.md


* YYYY - the 4-digit year during which the project proposal draft was submitted
* MM - the 2-digit month during which the project proposal draft was submitted
* short-name - a unique identifier for the project
* .md - the file extension indicating that the proposal is in Markdown format

When you begin drafting your proposal, you may not know the year/month of
initial submission or the ordinal identifier for the project.

The best time to set these values is immediately before committing the proposal
to the _proposed/_ sub-directory for the first time.  Only the person committing
the proposal needs to be concerned with properly assigning the values.

## Project Approval

Project Managers will ensure that pending project proposals are reviewed
regularly (at least once in a semester), assuming that there are
funds to be allocated to new projects.

The review process will follow the rules associated to the funding source
that the project applies to. Currently, only the LTS funding source is
accepting external project submission.

Depending upon the decision, the project proposal will be moved to the
_accepted/_ or _refused/_ sub-directory. It can also be kept in the
_proposed/_ directory, if the project proposal was good but not enough
funding was available to cover all the projects.

Accepted projects can go to the next step. Refused do not progress any

## Project Initialization

To be able to start execution, each project needs both an Executor and a
Reviewer. If there's no Executor, we need to find one by collecting bids
and selecting one of them. If there's no Reviewer, we need to appoint one.

### Collecting Bids to Find an Executor

If the project proposal did not propose anyone to execute the project,
then Project Managers will open a [request for
and record the issue's URL in the project file. The request for bid will
be open at least 2 weeks.

During that time anyone can submit a bid by filing a new issue. One
may opt to file a confidential issue if they want the details of their
bid to remain private. Or they can use a public issue but only send
the price offer by email to raphael@freexian.com. Issue templates are provided
to aid in the creation of both _Request for Bid_ and _Bid for Proposal_ issues.

The rules to select the winning bid vary depending on the origin of the
funding. Once the winning bid has been selected, Project Managers will
label the associated issue as "Accepted" and close the other bids' issues
with a "Rejected" label.

### Finding a Reviewer

If the project proposal did not define any reviewer, then Freexian must
appoint a reviewer. The reviewer can be a volunteer from the community
or someone paid by Freexian.

## During Project Execution

At the start of the project, Project Managers should create a new issue
labelled with [Project management](https://salsa.debian.org/freexian-team/project-funding/-/issues?label_name%5B%5D=Project+management)
should be created to host all conversations between the Executor and the
Reviewer (there is a dedicated template). The URL of that issue should be
added to the summary table in the project file.

Depending upon the scope of the project and how long execution is planned to
take, intermediary progress reports may be required.

For projects exceeding 10 billable hours or spanning more than 2 weeks, progress
reports are required for each 10 hours of work or every two weeks.

Progress reports should be submitted through the dedicated issue.  Use the
[Progress Report template](templates/Progress Report.md) in this repository to
assist in preparation of progress reports.

If the project incurs cost on a per-hour basis (as opposed to a flat cost for
the project), then approval is required from the Freexian manager before
incurring any costs beyond those agreed upon in the initial proposal.

## After Project Completion

Once the project is complete, a final report should be provided.  As with
progress reports (described above), the final report should be sent in the
dedicated issue.

The Reviewer will review the final report and may request additional
information or clarification.  If any additional work is required, the
Executor will be notified.  An amended final report should be submitted after the
completion of any additional work.

Upon acceptance of the final report, the Reviewer should submit a merge
request filling the completion date in the project file and moving that
file from the _accepted/_ sub-directory to the _completed/_ sub-directory.
The project management issue can be closed in the same operation by adding
a `Fixes #xx` instruction in the commit message.

### Invoicing and Payment

Generally, projects will be paid on a flat fee basis. It is expected that
large projects will be split in multiple steps, each with its own flat fee.

Invoices must be addressed to Freexian (see [administrative
data](https://www.freexian.com/contact/)) and sent by email to
[gerants@freexian.com](mailto:gerants@freexian.com). They will be paid
by wire transfer (or with Paypal if preferred). The email should
include a link to the bid's issue.


# LTS specific rules

Through its [Debian LTS and Debian
ELTS](https://www.freexian.com/services/debian-lts.html) service offering,
Freexian is funding CVE triage and security updates for the benefits of
its customers and the Debian community.

While this is a big achievement, we believe that we need to do more than
this to ensure the long term viability of the Debian LTS project. In
particular, we believe that we need to invest in infrastructure:

* we want to improve existing infrastructure that we rely on, in
  particular when our usage has created a burden for other Debian teams in
  charge of those infrastructure
* we want to create new infrastructure to enable new and better workflows

With the agreement of all paid LTS members, we are putting aside a part of
the LTS budget to be used in funding various projects.

# Who can submit projects?

Anyone can submit project proposals as long as they can explain how it
benefits Debian LTS (even if only in the long term). We welcome, in
particular, project proposals from Debian core teams that provide
infrastructure that the Debian LTS project relies on.

# How will project proposals be approved?

Ultimately, Raphaël Hertzog (as Freexian's owner) selects which projects
will be funded. But paid Debian LTS contributors will vote upon open
project proposals and it is expected that the result will be respected.

Depending on the outcome, a project proposal can be either:

* accepted: the proposal will be funded
* refused: the proposal is dropped
* deferred: the proposal is kept for a future vote (this is expected for good proposals when there's not enough funding to accept them all)

# Who can make bids?

If the project submitter does not want to implement the project
themselves, then anyone can make bids for the project.

# How will the winning bid be selected?

*This is still subject to internal discussion*

Selecting a winning bid is a highly subjective decision. One must put
into balance the experience of the executor, its relationship with Debian
and the affected teams, the expected cost, the desired quality attributes,

Freexian will thus delegate this decision to one specific person for each
project. Ideally that person is appointed when the request for bid is
opened and takes the Reviewer role too.

It is expected that the process somehow favors members of the
teams in charge of the infrastructure/software involved in the project.
Failing that, paid Debian LTS contributors would be preferred.

# Who will review the work?

If the project proposal does not define any reviewer, then Freexian will
appoint one of the paid LTS contributors as reviewer.

  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog <hertzog@debian.org>
  ⢿⡄⠘⠷⠚⠋    The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄⠀⠀⠀⠀   Debian Long Term Support: https://deb.li/LTS

Attachment: signature.asc
Description: PGP signature

Reply to: