Hi all,
The Inkscape board and SFC are interested in facilitating Inkscape
progress by gathering donations for funding targeted development work.
Below is a draft of a plan for how we could do this. I've run this by
the lawyers a couple times now, and informally presented it to the board
for comment, but before we get any further, I'd like to open it up for
public scrutiny. Once feedback has been incorporated, the next step
will be to have our board officially vote on it, and put it into
practice.
I've tried to model this as akin to a Summer of Code, except the
projects are funded by our community through official fundraisers, and
the work taken on by Inkscape developers rather than students. I think
this could be very important to moving our project forward in a big way.
Please take a few moments to review this plan and share with me your
questions or ideas on how it could be made better.
Thank you,
Bryce
------------------------------------------------------------------------
Inkscape Funded Development Model
---------------------------------
1. Fundraising
===============
Using the model we'll describe below, anyone may start an official
fundraiser for Inkscape development. We leave it to your imagination
how to structure and run your campaign, so long as a few requirements
are met.
First, the person who organizes and supervises a fundraising campaign is
termed a Fundraising Coordinator. We may have multiple coordinators if
we have multiple campaigns, but only one coordinator per fundraiser.
They have three duties:
a) Administration of the fundraiser
b) Allocate raised funds to projects
c) (Optionally) Be involved in final signoff of completed projects
The first duty is left to the Fundraising Coordinator's discretion.
The second duty should be straightforward. When the fundraiser is
completed, all funds must be allocated to one or more projects in the
official Jobs List. No guarantee is made that any given project will be
undertaken if there is insufficient developer interest, but future
fundraisers can up the funds allocated to it to stimulate interest.
We expect some campaigns will wish to target one or more specific
projects, and announce this upfront to stimulate donations. This is
fine to do, but keep in mind that projects can change (or get
implemented) while the campaign is under way. So instead of naming
specific projects, it may be better to describe the types of projects
the campaign is aiming to fund, and make the specific decision(s) when
the fundraiser is over.
For ongoing fundraisers, the coordinator responsible for setting it up
can specify the distribution programmatically (e.g. "distribute evenly
to the four oldest projects in the list as of the end of the campaign",
or "10% to each of the ten projects with the highest funding from past
campaigns", or "allocated evenly across all documentation projects
registered as of the start of this campaign". The coordinator will
remain responsible for administrative duties for the length of the
fundraiser; if they choose to step down, the fundraiser is terminated
(but another coordinator can start up an equivalent to replace it, under
their own funding distribution preferences).
The third duty - signing off on completion of the project - is described
in more detail below. The Fundraising Coordinator *can't* do this if
they personally contribute most of the funding, because it'd run us
afoul of IRS rules.
2. Proposing New Projects
==========================
We maintain a listing of proposed projects. Anything can be proposed,
including feature development, bug triaging, documentation,
administration, etc. It must have a defined deliverable and acceptance
criteria identified, and a time limit for how long the work should take.
(See appendix for an example set of Acceptance Criteria.) Initially
these are all made available for volunteers to do freely. When GSoC
rolls around we use them as suggested projects for students to
undertake.
Any project that remains on the list unfinished for 6 months becomes
eligible for funding the work. (This is so that any proposed projects
that are fun or easy get done by volunteers, and money can be focused on
harder unsexy work, and to make abuse harder.) We'll call these
eligible projects 'jobs'.
3. Fundable Jobs List
======================
The money from these fundraisers goes to the Inkscape Foundation account
administered by the Software Freedom Conservancy, who takes a small
percentage of each donation. Conservancy is a US 501(c)(3) public
charity, and all donations are tax deductible in the United States as
allowed by law.
We maintain a list of allocations-to-jobs so we can keep track of what
money "belongs" to which job, so the correct amount is paid when the job
is done. This amount is displayed on the web for developers to browse
when selecting a job to do.
Anyone in the Inkscape AUTHORS file is eligible to apply for a job.
The applicant must submit a Job Proposal, which will identify the
applicant's qualifications for doing the job, and outline how they
intend to do the implementation.
The Inkscape Board will delegate one of its members to review and vet
applicants to help ensure the best candidates are selected for each job.
For larger, longer, or more complicated jobs the vetting may take some
time, but for moderate sized jobs the intent is for a decision to be
made within a few days. The Inkscape Board may elect to mark some jobs
(such as smaller ones) as Pre-Approved; once the applicant files an
application they may begin the job immediately, no vetting required.
No one may assign themselves more than one Pre-Approved job at a time,
and the Board reserves the right to subsequently review the application
and disapprove it in case of problems.
When an applicant is assigned the job, the clock starts ticking. The
applicant must post at least one progress report each month (e.g. to a
blog or to the Inkscape wiki). During the time limit, so long as the
monthly reports are being clearly posted, no one else can apply to do
the same job. If two months pass without a report, or when the 6 months
time runs out, and the job is not completed, the assignee doesn't
receive the funds and can't attempt the same job again for 6 months.
The job is considered completed when the identified deliverables are
delivered according to the specified criteria.
4. Completion Criteria
=======================
The Reviewer makes the decision as to whether the job has been
adequately completed, using the originally specified criteria.
By default, the Fundraising Coordinator is the Reviewer; if the project
was funded from multiple sources, the one that allocated the largest
amount of funding (or their chosen delegate) is the Reviewer. This
person must formally accept the Reviewer role by email within 1 week.
For any reason, they may opt to decline the Reviewer role. If they are
unresponsive or opt to decline the role, it passes to the next
Fundraising Coordinator. If no Fundraising Coordinators take or
delegate the role, then the Inkscape Board will delegate a Reviewer.
However the Reviewer is decided, he or she must be a different person
than the original Project Proposer, and neither the Reviewer nor the
Reviewer's employer may contribute more than 50% of the total funds for
the given project. We want to avoid a situation where a person or their
employer has an independent business interest in seeing the job
completed, and is over-involved in the management of the work.
If someone other than the assigned Developer performs the work, to the
satisfaction of the Reviewer, then the assigned Developer will receive
70% of the funds. The remaining 30% are returned to the Inkscape
general fund.
5. Termination and Modification
================================
The original proposer of the Project or Job may withdraw it or modify
its definition at any time, so long as someone is not signed up for it.
If the Project is withdrawn, all funds allocated to it return to the
general Inkscape fund.
Unassigned Jobs expire 24 months after their initial project proposal.
This is intended to clear out deadwood projects.
Any funds allocated to that job are moved to Inkscape's general fund.
6. Process Exceptions
======================
Historically, all development work funded by the Inkscape Project
required authorization by the Inkscape Board of Directors; this funding
model is to establish a structure for development funding that does not
require Board involvement. However, the Board retains the ability to
authorize exceptions for anything outside the bounds of this policy, to
be handled on a case-by-case basis, with decisions made by a majority
vote.
In particular, the Board may select by vote certain projects to be
immediately fundable, without needing to wait the normal 6 month period.
They may also withdraw any project or job at any time, by majority vote.
The Board may also make changes to this policy via a normal majority
vote.
7. Conflict Resolution
=======================
If there are any problems or disagreements once a project has been
assigned to a Developer, a Meeting can be called by any stakeholder
(Project Proposer, Developer, Fundraising Campaigns, Reviewer, or
Inkscape Board Member). For proper quorum, the Meeting must be attended
by the Developer, the Project Proposer, the Reviewer, at least one
Fundraising Coordinator, and one Neutral Developer (whom can be anyone
in the Inkscape AUTHORS file selected by the Developer). Any unanimous
decision reached in this Meeting is binding on all parties.
Any conflict that can't be resolved via a Meeting may then be escalated
to the Inkscape Board of Directors, who will be the ultimate arbiter.
Conflicts of interest, including conflicts with the board, are governed
by the Software Freedom Conservancy's org-wide conflict of interest
policy.
Appendix: Example Delivery and Acceptance Criteria
===================================================
# This is a sample set of delivery and acceptance criteria; each project
# may use, alter, or replace any of these conditions as appropriate.
a. Test cases are provided to add coverage for all newly added
functionality.
b. Documentation patches provided for describing all newly added
functionality.
c. Updates provided for release notes, NEWS, bug reports, etc.
d. All patch(es) have landed in the official upstream repository. Either
in the mainline tree, or in an officially designated branch as per
upstream policy.
e. Code builds and runs on the major platforms supported by the
project.
f. Code passes the upstream project's designated style/lint checking
tools.
g. User-visible strings are translatable as per project policy.
h. Unit and regression test suites pass with no new test failures.
At project completion, once the above criteria is met, 90% of the
payable funds are delivered. 10% is held in reserve for bug fix
followup: One month after completion, a list of up to 10 identified
bugs can be specified by the Reviewer to be fixed; if all 10 are fixed
within a month, the remaining 10% of the funding is released to the
developer. If no bugs exist, or none are specified before 6 weeks
after completion, then the developer is paid the 10% directly.
