Grants: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(signing)
No edit summary
Line 1: Line 1:
=Mozilla Foundation Grants=


Mozilla Foundation grants are a way to get paid as a contributor, for important work that benefits the Mozilla project. Unlike Google Summer of Code grants, the amount of time and money involved are flexible. And unlike many grants from very large governments and organizations, the grant process is designed to be lightweight, and focus everyone's energies on what's important -- actually getting good work done.
Mozilla grants are a very flexible opportunity for getting deeply involved in Mozilla. It can lead to more experience and potentially job offers in an area you're interested in working, yet not interfere with other work or with school. It's not too difficult, but, you'll have to prove that you have a good idea and that you're the right person to follow through on it.
==Relationship to Mozilla Community Giving Program==
The [http://blog.mozilla.com/seth/community-giving-faqs/ community giving program] is another way that Mozilla contributors can be compensated for their efforts. That program is needs-based and provides thanks and support to community members who are already contributing in a given area. It can be a complement to the grant program, in terms of offsetting costs for items such as equipment, travel and other expenses. However, there is no contract, and thus there is no guaranteed compensation. In addition, the giving program does not usually directly pay for the time of the volunteer.
In contrast, the grant program is for payment on a proposed body of work which is planned ahead and tied together with a proposal. The developer is no longer strictly a volunteer, because there is a contract which guarantees payment for their time on the project.
==Grant Manager==
The grant manager is your key contact with the Mozilla Foundation. Their reputation is on the line in terms of Mozilla getting its money well-spent. They will be responsible for ensuring that the proposal is sound, and will decide when milestones have been reached (important for getting paid). However, the grant manager does not need to work for the Mozilla Foundation. They are mainly advising both parties, but do not typically deal with contracts or payments.
A grant manager is also usually one of the main mentors, and will be very helpful as a resource and guide. See the next section on [[#Grant_Topics]] to see how to find your grant manager.
==Possible Grant Topics==
There are many possible subject for grants. Grants do not have to be directly in the Mozilla codebase, or even in code at all, to benefit Mozilla. Some possible areas for grant-related work include:
* Accessibility - grant manager [mailto:aaronleventhal@moonset.net Aaron Leventhal]. The [[Accessibility/Projects|Accessibility projects page]] has some ideas for grant topics, but in reality the possibilities are limitless. The overall goal is to help users with disabilities, the web and open source accessibility.
* Security -- grant manager unknown
* XUL as a platform -- grant manager [mailto:zak@mozillafoundation.org Zak Greant]
* [http://starkravingfinkle.org/blog/2007/01/thinking-about-a-xul-validator/ XUL validation] -- grant manager [mailto:mfinkle@mozilla.com Mark Finkle].
* Other -- have a good proposal? Find someone experienced in the community who is willing to be your grant manager and liason with the Mozilla Foundation
==Grant Proposal Process==
Here are the basic steps for getting a Mozilla grant.
# Get project idea: think of a good, self-contained project that isn't just "fixing bugs". It should be exploring or implementing some new area. Alternatively, ask around for good ideas.
# Solidify a plan: discuss it with the grant manager or module owners for that area until you agree that the basic idea makes for a good grant.
# Divide the work: if this is the first grant, decide how much work can be done for less than $10k, because that's how much a typical first grant will provide. You may decide to make the first grant a small exploratory grant, where the main deliverable is a plan and proposal for the second grant. Follow-up grants can ask for more money.
# Draft a proposal: utilize community help to review and edit it. The proposal does not need to be perfect, but it should answer most of the basic questions an expert in the area would ask.
# Have it sent in: ask your grant manager to send the proposal to the Mozilla Foundation and CC you.
# Wait for a decision: this can take between 2-6 weeks. Mozilla is usually fast, but realistically it depends on what else is going on, and may depend on when the board is next planning to meet. The grant manager may be able ask Mozilla for an estimate for when the decision will be made.
# Get the contract signed: at this point your grant manager will give you the contact information of someone you can work directly with to get the contract and first payment. It's a good idea to CC your grant manager on any email exchanges, if you're anxious about when/whether you will get a response. Signing by both parties can be achieved using a scan and email process (PDF).
# Do the work, and keep the grant manager, mentors, peers and community up-to-date on your progress. It's a great idea to keep a project page on a wiki.
# Work with the grant manager to decide when the major milestones have been reached, so you can get paid. Mozilla Foundation will ask you to submit an invoice.
# Finish the work, of course!
# Work on the next grant proposal ...
==Grant Proposals==
The total length of the proposal does not need to exceed 2-4 pages, but more information is okay if it helps the grantee research the project. The format should probably be HTML, since some version of the proposal may end up on the web for others to learn from. PDF's are not a problem.
The proposal is usually written up by the grantee, and then reviewed or edited by the grant manager for that particular grant area. It may also be reviewed and edited by one or more mentors or peers.  When it is finished, the grant manager will send it with an introductory email to the Mozilla Foundation.
* Header
** Title for grant
** Name of grantee (organization or individual).
** Who the other participants (e.g. other mentors, and the manager of the grant)
** Estimated project start and end dates. This is only to give everyone an idea, but in reality the dates are flexible
** Amount of funding requested, and the estimated amount of the project budget overall (if different)
** Whether the grantee is a 501(c)(3) nonprofit or has a fiscal sponsor that is a 501(c)(3).
** A list of other current or pending funders for this project (if applicable)
** Proposed license (if this is completely new work then Mozilla will the copyright holder and will have the final decision).
** Other relevant details on plans to share work, if any.
* Body
** Introduction and background
** Problem: a description of the problem the project solves
** Proposal: a description of the solution
** Expected outcomes (what will be the end result?)
** Benefits, including non-obvious things such as feedback that improves other projects. Also include how the project is aligned with the [[http://weblogs.mozillazine.org/mitchell/archives/2007/02/the_mozilla_manifesto_introduc.html Mozilla Foundation's mission]].
** Other work in this area, how it ties in or relates
** A work plan (methods, work items, milestones). Describe payment milestones if different from those in [[#Payment]] section below.
** Potential issues that could affect results
** Deliverables -- include documentation and useful input into other projects
** Success criteria (how will the grantee measure what did or didn't work?)
** Use of extra time (for large grants) or possible areas for future work on this topic
** Relevant grantee skills experience -- why are you the right person for this grant? Include Bugzilla query links to show bugs fixed, or links to other project pages, etc. Showing previous Mozilla or at least open source community experience is very helpful.
==Payment==
The Mozilla Foundation will typically pay in thirds, but this could vary by grant. The grant manager will help decide on the milestones.
# First payment on acceptance of the proposal and signing of the contract
# Second payment on feature completeness and beginning of community feedback process (typically the grantee will need to provide information to the newsgroups or via a blog and have a way of collecting feedback)
# Third payment on final polish, including incorporating or responding to community feedback (some of this may go into the next proposal).
==Travel and Other Expenses==
In some cases it's very helpful to travel to conferences or meetings related to the area of work. You may also have some other expense that you feel justified in asking Mozilla to cover.
This can be dealt with separately from the grant, but it's a good idea to bring it up as soon as possible.
Certainly, you can only expect to be reimbursed for expenses for items that are approved before the expenditure occurs.
==Strict or flexible?==
The Mozilla grant process is fairly flexible. The whole point is for good work to get done, and for us to enjoy that work as a community, and not to get caught up in things that don't matter. If you find yourself filing or fixing a bug you find, that's unrelated to the grant, great! Or, if you have a new idea to do things in a better way, great! Go ahead and mention those things to the grant manager. If you end up with deliverables that are as good or better than what the grant asks for, that's not generally a problem. Of course, it's always good to check with the grant manager or community before making any major changes of direction.
==If you finish too early==
If you make progress faster than you anticipated, feel free to add to it. It will only help you get a larger grant for the next round. There's plenty of work to be done -- I haven't seen any concern about running out of work (grin).
==If things are taking too long==
In some cases the grantee underestimated the amount of work to be done. This often happens, and is not necessarily a cause for concern. Yet, it can be a source of anxiety and frustration, because the grantee wants to do a good job yet probably is counting on the money. Generally the grant manager will work with you to redefine the milestones and get you paid up, and a new grant can be started to complete the work.
==If you can't finish==
If you start a grant and need to stop before finishing, it may be an understandable situation. For example, you may be offered a full-time job which will not allow you to finish the work. In this case, Mozilla will simply end the contract and you will not be paid for the final milestones. This is not a problem.
==Follow-up Grants==
There may be several follow-up grants. If you did amazing work on the first grant then you may consider asking for a longer, more ambitious grant.
In fact, in some areas that need initial research, the first grant may be purely exploratory, with the main deliverable being the next grant proposal for the actual work. However, this is only the case for extremely new topics.

Revision as of 20:33, 16 May 2007

Retrieved from "https://wiki.mozilla.org/index.php?title=Grants&oldid=57010"