User:RKent/Donations Proposal

From MozillaWiki
Jump to: navigation, search


On November 18, 2013, I ( or submitted a message on the tb-planning list, requesting:

I would like to propose that for Thunderbird 31, we add a donation user interface and mechanism that requests an annual donation of $10 from users. This should be something that appears prominently once after the upgrade, and users have a choice to act/postpone/or ignore (until next major release).

Here I would like to give more details to that proposal, and submit this for formal approval by the governing body for the Thunderbird project.

Why is this needed?

Mozilla has decided that they will not continue to fund innovation in Thunderbird. Mitchell Baker, in her blog post [1] announcing the reduction in resources devoted to Thunderbird, stated that "Much of Mozilla’s leadership — including that of the Thunderbird team — has come to the conclusion that on-going stability is the most important thing, and that continued innovation in Thunderbird is not a priority for Mozilla’s product efforts ... focusing on stability for Thunderbird and driving innovation through other offerings seems a natural choice." Some of us however still believe that Thunderbird could and should be a vehicle for innovation, and would like to see it move forward. If funds are needed for that, then we will need to raise those funds outside of existing Mozilla resources. Asking users for donations seems like one viable method to do that.

There is also a certain risk that at some point in the future, Mozilla will decide that they have critical needs for funds in other areas, so that even the existing subsidy provided by Mozilla to Thunderbird is too much. With its current immature means of fund raising, loss of that remaining subsidy would be devastating to Thunderbird. To mitigate this risk, Thunderbird should learn to be fully self-sufficient through funds generated from the product.

Plan for Donation Link

The exact details of the donation link within the Thunderbird product will be managed using normal channels of patch landing with review from relevant module owners or peers. But for purposes of this proposal, let me give a brief description of some of the particulars.

When Thunderbird detects that it has updated to a new major release, a new tab will be opened and given focus that loads a webpage (linked to some page) describing the request for a donation of $10 to support Thunderbird development. In addition, a Donation link button will be added to the status bar or other location that is continually visible. The Donation link button will offer the user choices of donate, ask later (after about a week), or stop asking. Both the donation link button and the donation tab can be suppressed with a hidden preference (intended for use in enterprise rollouts). "Stop Asking" is intended to mean "Stop asking until the next major release" so the wording may need to be tweaked to make that clear.

The resetting on major release will intentionally repeat the appearance of the domain link every 6 weeks for beta users. They are testing the link and page, and seeing it regularly should be understood as part of the testing. For most users, the donation link and tab would not reappear for 42 weeks.

There was some discussion on the tb-planning list that the possibility should exist for a recurring payment donation. I don't take any position against this, but my opinion is that an annual small payment is sufficient. But the Thunderbird governance bodies should take a position on this.

Uses of Income from Donations

The actual uses of the donation income will be decided by a formal group with fiduciary responsibility (described below). But here are some suggestions to highlight the need.

Just to be clear, donations that are given would not be tied to specific purposes, but would instead be devoted to the project as a whole.

  1. Engagement

    For purposes of this proposal, "engagement" activities are efforts designed to strengthen and broaden the community of Thunderbird contributors, without targeting any particular individual. At the least, it should include an annual conference of Thunderbird key contributors where we can do planning, coordination, and some R&R as reward for past efforts. Other possibilities could include funding of specific outreach activities (say travel expenses for a Thunderbird presenter at a FOSS event).

  2. Compensation to Mozilla for Infrastructure and Support

    A portion of the collected funds could be used to offset some of the subsidy that Mozilla currently gives indirectly to Thunderbird by providing build, release, and tracking infrastructure.

  3. Non-living support to specific volunteer contributors

    Existing volunteer contributors incur financial costs related to the project for things like equipment, internet connectivity, travel to conferences, etc. There could be a mechanism to recognize key contributors by providing grants to individuals to offset some of these expenses, tied to reimbursing specific project-related expenses.

  4. Hire contractors for specific purposes

    Individuals could be contracted to provide project support. That could include areas such as website development, public relations, addon reviews, or support for development in certain targeted areas (such as the current need for help to finish the new Address Book).

  5. Support for ongoing expenses of possible server-based innovations

    In some cases, innovations in Thunderbird could involve related server operations, as has also occurred in Firefox. Examples: mechanisms to distribute S/MIME public keys, or to provide storage for a "if your email client does not display this email correctly (the way that Thunderbird does), then click here to view it in your browser." These are not proposed here, they are merely examples.

Financial Management of Donations

Ownership of donations, if possible, should be directly under the Mozilla Foundation, using a specific fund to handle donations and expenditures under fund-based accounting rules. Mozilla will need to decide if this is feasible or advisable, or if an alternative under the Mozilla Corporation would be better. But the Foundation provides a more solid 501(c)(3) legal structure, as well as better visibility to expenditures than is currently provided by the Mozilla Corporation.

Thunderbird needs a governing body that is capable of making decisions for uses of funds in a way that is acceptable to the community, as well as appropriate to the legal status of Mozilla. Such a body does not really exist at the moment. Possibilities within the current framework, and their weaknesses, are:

  1. The current group of module owners and peers for Thunderbird. This group is primarily focused on development, and therefore leaves out key voices in support, quality control, and marketing. The group also has no history of regular meetings or organization that could provide leadership or accountability.

  2. The current release drivers group. This group is dominated by Mozilla staff, and is unlikely to have the confidence of the Thunderbird Community as representing their broader interests.

  3. The current Business Development & Legal role (currently Jean-Baptiste Piacentino): This role is also very tied to Mozilla staff, and during the community-driven phase of Thunderbird has not been very actively engaged.

The appropriate body to manage expenses is partly determined by the scale of funds available. For purposes of this proposal, I will assume that there are approximately $100,000 of funds available, and these funds come primarily but not exclusively from individual donations.

I propose that a new module be created within the Thunderbird general area that covers "Finances and Planning". That module would be expanded to include additional stakeholders beyond the developers who currently dominate the module owners and peers, including potentially 1) major volunteer contributors representing support, QC, and marketing, 2) representatives of other organizations who make significant donations or are otherwise significant stakeholders, 3) key Mozilla representatives such as JB and Gerv, and 4) developers who are interested in strategic planning for Thunderbird.

At the same time, I would expand the definition of the relevant Module Owners and Peers for the project to include not only the Thunderbird modules, but also Mailnews Core and Calendar, as both of those areas contain people whose primary contribution is within Thunderbird. This expanded group of Module Owners and Peers (including the new people in "Finance, Operations, and Planning") would become the larger group specified in the current Governance document as "The module owners group at large decides by consensus money spending community propositions."

That expanded Module Owners and Peers group is too large to make routine spending decisions, but would formally agree to major directions if necessary, delegating regular decision making to the "Finance and Planning" module and peers. In addition, that module would appoint a Treasurer who would be the sole contact to the Mozilla accounting structures to provide any required information including approving specific expenditures as meeting the requirements of existing plans. The Treasurer would also provide regular reports to the Thunderbird community on use of funds.

Process for Approval of This Proposal

According to New Release and Governance Model, some of the processes for dealing with project issues and donations are described. In particular, the following is stated:

Money generated by donations is to be used for engagement or other purposes. Donations are for general purposes. ... The module owners group at large decides by consensus money spending community propositions.

There is an additional governance body mentioned there, the "Release Drivers". That group has a number of defined roles, including overseeing "Business Development & Legal (with a veto right by paid Mozilla staff)." There is also mention specifically of a virtual sub-module with the following name and responsibility: "Business Development (BD): in-product partners inclusion & revenues" although I could not find any evidence that this module actually exists in the official Module definition wiki.

Any or all of those groups could claim responsibility for the approval of this proposal. I will try to engage everyone to cover all bases.

That means, based on the current list of people, that all of the following are involved in this decision process:

Thunderbird Module Owners and Peers:

David Bienvenu (:bienvenu), Mark Banner (:standard8), Blake Winton (:bwinton), Magnus Melin (:mkmelin), Mike Conley (:mconley), Siddharth Agarwal (:sid0), Joshua Cranmer (:jcranmer), Justin Wood (:callek), Jim Porter (:squib), Florian Quèze, Patrick Cloke (:clokep), Andreas Nilsson (:andreasn), Richard Marti (:paenglab) Josiah Bruner (:JosiahOne)

In addition to these Module Owners and Peers, the Release Teams adds a few additional names:

  • Back End Integration Engineer: Irving Reid
  • Quality Assurance: Ludovic Hirlimann
  • Web Development: Andrei 'Sancus' Hajdukewycz
  • Support: Roland Tanglao
  • Release Engineering: John Hopkins
  • Business Development & Legal: Jean-Baptiste Piacentino

So these are the people to whom this proposal will be submitted for approval. The relevant Mozilla staff will need to decide if the proposal also needs to be submitted for approval to other Mozilla staff (as I suspect that it will).