Skip to main content

Guidelines for Management of Working Group Funded Development Efforts and Initiatives

Version 1.0 January 21, 2022


At the Eclipse Foundation, most open source projects progress using developers who are employed by members, self-employed, or volunteers. In some instances Working Groups may, in exceptional circumstances, choose to allocate a portion of their budget to fund development efforts in support of the projects within their purview. Working Groups with applicable budgets are able to take advantage of an initiative to spend funds to contract development efforts to advance the working group and/or its associated projects.

Such funding is over and above the more typical way projects and initiatives get advanced. Examples of such development efforts include project process enhancements or updates, addressing outstanding issues or other inhibitors preventing use or adoption of the project(s) in their current form, or addressing issues related to the working group hosting a version of its own project(s) (e.g., the Open VSX initiative within Eclipse Cloud Development Tools working group), etc.

In order to carry out such development efforts, the Eclipse Foundation will manage the development effort on behalf of the working group. The Foundation will, in turn, seek to engage with capable service providers to see that these development efforts get carried out.

About this Document:

This document is intended to provide guidance to working groups on how the Eclipse Foundation will carry out this management and to identify the various roles and responsibilities associated with these types of efforts. This document is neither exhaustive nor binding but rather describes the general process; specific roles, responsibilities and tasks which will be decided upon in each individual case.


The Eclipse Foundation (EF) will engage with the Working Group's Steering Committee, or their delegate if so designated (for example, the Planning Council in the Eclipse IDE Working Group) as the key stakeholders in the community to determine the highest priority development effort requests to be addressed, convert these priorities into actionable development tasks, and then engage with qualified resources to carry out these tasks.

The guiding principles of the process are:

  • To adhere to the principles of transparency and openness,
  • To complement the existing community development efforts,
  • To encourage a “multiplying effect” where community participation is amplified by this funding program's undertakings,
  • To ensure the funds allocated fit within the overall working group program plan and budget.


Arranging for the implementation of development efforts and initiatives will be managed exclusively by the Eclipse Foundation on behalf of the working group. The EF commits to being transparent with regard to with whom it has chosen to engage and a summary of the expenditures made on behalf of the working group. Having said this, the EF recognizes and supports that pricing for services is considered confidential by many vendors, and the EF will work to respect that confidentiality while still ensuring working group members are aware of the total value being delivered.

The Foundation will designate an individual to manage the various tasks on its behalf (the “EF Rep”). It is expected that the Steering Committee or other committee will name one to three delegates to collaborate with the EF Rep. The delegate(s) can come from within the Steering Committee or another working group body, or their designate if more appropriate. Together, the delegates and the EF Rep form a small ad hoc team (the “Team”).


The amount of funds available for development will vary, and will be subject to the available Working Group funds as allocated in the working group budget.


To create a process that is easier to track, budget for, and measure success, development will be done through a series of phases:

1. Identify the Prioritized Development Efforts

The Steering Committee or their delegate(s) will provide a prioritized backlog of enhancements that are to be implemented. These will typically be in the form of open issues or bugs in the community, and sufficient in detail to allow for potential vendors or committers to understand the desired outcomes and to sufficiently investigate the effort involved in carrying out the development.

From this input and interaction, the Team will capture this list as a set of desired development efforts in a form that will allow vendors and/or committers to put forward proposals for carrying out the development efforts. The Team will also identify the relative allocated budget to assign to each of the development efforts.

The description of each Development Effort is expected to include, as a minimum:

  • task name and Gitlab Issue id,
  • time estimate, if possible,
  • expected deliverable(s)/outcome(s),
  • identify any dependencies on external resources including Eclipse IT infrastructure updates,
  • means of demonstration and/or verification of completion.

2. Bid Solicitation and Contract Process

The EF Rep will decide, with consultation with the Team, the most effective way to solicit bids. This may include an open bidding process, though that is not a requirement if it is felt doing so is unlikely to lead to competitive bids. If an open bidding process is chosen, it is expected to be approximately 2 weeks in duration to enable potential contractors to interact with the EF Rep to seek additional information regarding the development efforts.

Regardless of process, the Eclipse Foundation may solicit bids from specific committers, Members, and/or contractors should it feel particular expertise or experience is required to be successful. In addition, it is expected that the Team will suggest potential committers and/or contractors they believe have particular expertise or experience as well. Any bids submitted by contractors/committers may be noted as confidential bids to protect the submitter's pricing strategy.

Typically, each development contract will include the following:

  • Description of the approach to address the Development Effort,
  • Identification of who will perform the work (i.e., named developers),
  • The proposed timeframe for the development effort,
  • Any dependencies/caveats that exist that must be addressed,
  • Proposed outcome for the work, including how to demonstrate the work has been completed,
  • Explicit list of deliverables, including any interim deliverables,
  • A proposed price, including whether the bid is being made on a fixed price or time and materials basis.

Potential contractors may request that any bids or negotiations with EF be treated as confidential for competitive reasons, and EF will work to accommodate such requests to the extent possible.

However, all contractors must agree to EF disclosing the name and total value of any contracted Development Effort.

The output of this phase is a documented and agreed Statement of Work.

3. Award of Contract(s)

In evaluating proposals from vendors, the EF will base its decisions on the following criteria:

  • Price and timeliness,
  • Plan for proposed development and deliverables,
  • Skillset of proposed developers, with preference given to committers in the relevant area,
  • Bidder's relationship with EF, with preference given to either Contributing Members with committers, or self-employed committers with relevant expertise,
  • Any additional relevant elements in the bid, including delivery date, whether fixed price vs. time and materials basis, etc.

Contractors will be expected to execute a Services Agreement and Statement of Work (SOW) with the Eclipse Foundation for each winning bid.

4. Sign-Off on Completed Statement of Work

To assist the EF in managing the individual development efforts, the Team will advise EF Rep on the satisfactory completion of each development effort. For each Development Effort, the contractor is expected to provide:

  • Open source code. In most cases, it will be expected that the acceptance criteria for code is that it has been committed by the relevant Eclipse project. Other scenarios may be possible in exceptional circumstances,
  • Test harness(es) for code,
  • Documentation, including appropriate documentation related to Intellectual Property. This includes updates to the relevant public bug(s)/issue(s),
  • Any other appropriate deliverables, including those to which the contractor committed in the original SOW.

Back to the top