Subscribe to our mailing list to receive notifications about open RISE RFPs.

Background

RISE improves the software ecosystem for RISC-V by working directly with upstream open source projects to support the RISC-V architecture. Companies that have pledged support to RISE will make some contributions to these projects, but it is not expected that they will have all the needed expertise. The Request for Proposal (RFP) process allows RISE to extend its impact by supporting others to do the work that the Technical Steering Committee (TSC) identifies. The RFP process strives to be open and transparent, in the spirit of the open source communities in which it participates.

Process

RFPs will go through a series of stages throughout their lifecycle, from planning to execution to resolution. This section will highlight the required process

Conception: Identification and Socialization

An RFP begins when  a need is identified that requires additional engineering resources. The need may be identified by anyone including a member of the RISE TSC, a RISE WG, the RISE Governing Board, or a company or individual external to RISE. When a need is identified, the appropriate RISE WG will vet the opportunity and if valuable, the WG will put together a brief proposal to socialize within RISE to gauge interest and support for this need. This socialization step helps RISE prioritize efforts early in the process.

RISE proposal form

Formation

Once a proposal has been reviewed by the TSC and has support to move forward.  TSC will present recommendations for RFPs to the Governing Board (GB) for approval.

Approval for Bidding

GB will vote on proposals from TSC.

Publication

There will be a public location of approved proposals and their status as RISE strives for transparency. 

• Open/New  

• Bidding notice via LinkedIn Post
• Bidding to remain open for 1 week minimum
• Contractors can submit bids via Google Form on the Project wiki

• Closed/Awarded

• Bidding is closed

Review and Approval of Proposals

• WG/Tech Lead (TL) will review all proposals
• Reviewers will be pre-named in the proposal

• Must have a minimum of 3 - example
  • TL of the Proposal
  • TSC lead
  • TSC lead
• WG/TL will recommend proposal(s) to GB
• GB will have final approval for contract award 

Contracting

• You will receive an email informing you of your bid acceptance. the email contains a form you must complete with required contract information.
  • Once complete please allow 7-10 business days for the contract to be sent for signature
• Contracts will be written using the Standard Linux Foundation Europe Paper with the SOW and payment schedule added as an addendum. 
  • Please review prior to your bid submission to address any concerns.
  • Contract Language is not negotiable as Linux Foundation will be contracting the work and paying the invoices.
• Once executed the Technical Lead will reach out to schedule a kick off call.

Execution

• WG/TL will manage the contractor  
• Weekly contractor reports are encouraged
• Milestones/deliverables may be defined in the Contract/Statement of Work (SOW) 
• Updates are expected as an open project for that WG
• Wiki project updates
• WG deep dive
• Any challenges are to be brought up and addressed with TSC

Invoicing

• Please include the HFO# listed on your signed agreement, this is the PO#, 
• Please include the RP# on all invoices (RP00x)
• Invoices should be sent to your Technical lead with a short description of the work the invoice is covering. This can be links to your weekly reporting or a high level outline.
  • DO NOT send invoices directly to Linux Foundation AP, this will delay the approval process.

Concluding the Work

• WG/TL will monitor the contractor until tasks are complete (per SOW)
• WG/TL will conclude all work with contractor
• All invoices are to be approved by WG/TL for payment