Initial Review

OCV has scraped some high level information on 28k of all Github projects for consideration as of April 2024

Projects with greater than or equal to 20 monthly merged pull requests or 5,000 stars (https://handbook.opencoreventures.com/company-formation/) with permissive licensing (https://handbook.opencoreventures.com/building-the-product/software-licensing-terms/ - MIT, Apache, BSD) will be considered for initial review. Filtering on the above projects list yields approximately two thousand projects.

In the initial evaluation of potential projects, pasting the Github repository URL into an OCV slack channel will yield some information and enable the creation of a research document.

Some fields will be pre-populated by the creation of the research document, while others will need to be filled out in an initial review. A reviewer should check the following before putting a project ahead for full research.

1. Source - add where the project came from.
2. Activity - if the project is no longer as active as it once was, it may not be a good fit. Check that it still meets the activity benchmarks above.
3. Incorporation - check if the project has an existing company around it. Websites associated with the project may be a good source of information as may looking at the linkedin profiles of top contributors.
   1. Small companies which are not venture backed or provide consulting services (and don’t sell software as a service) may be okay to still pursue.
   2. Companies backed by large corporations may still be interesting for example if a large company has abandoned it or we are able to poach talent.
   3. Avoid cryptocurrency and blockchain projects.
4. Business case - if a project is active and doesn’t have an existing company around it, it still may not make sense to start a new company around if there is not a good business case to be made. Checking for large competitors in the same market may provide a barometer for this.
5. Location of key contributors are in geographies where we can’t hire.

If there are no outstanding limitations from an initial review, ask an OCV partner if the project seems commercially viable.

A reviewer will mark the project under Status in our tracker as either Research TODO and provide an Assignee the project for full research or mark it Closed Project and provide a Reason Closed.

Full Research

There is a backlog of projects with some initial review completed. By default they have a P-level of Other and when an OCV partner recommends a project, it will have a higher priority (P-1) and skip ahead of potential research in a backlog. A reviewer is not to get started for P-1 projects.

Full research will begin with some information in the research doc from an initial review and build upon it to form a more complete picture and provide actionable next steps.

1. Researchers should add their name to the assignment in the document along with any notes from partners about a project.
2. Researchers should provide and explain the technical background of a project sufficiently to a non-technical reader.
3. Researchers should also gather information including online professional (LinkedIn, blogs) profiles, project commit activity, professional information, location, and emails of top contributors to projects.
   1. In order to find (non-work) emails for contributors try the following:
      1. Their online profiles
      2. Contactout for LinkedIn
      3. Github commit examination
         1. Find a commit on a contributor profile
         2. View commit details
         3. Add .patch to the end of the url.
         4. Review for an email that is not attached to @users.noreply.github.com.
   2. Review if contributors are
      1. Contributing for the longest or a long period of time relative to others
      2. The the highest or a high ranking contributor over all time and recently
      3. That they are currently active as a contributor
      4. Located in geographic regions where we can’t hire
4. Information on the market should be provided along with a review of the competitive landscape - both in terms of companies and other projects.
5. Researchers should also provide conclusions about the market, project, and top contributors.
6. Researchers should be aware of what may be blockers and should not spend additional time on certain projects. Those where there are potential blockers but are P-1 should be highlighted for review with that partner.
7. Reviewers should take a look at the full research and discuss any questions about the market, project, or contributors in the #research slack channel or during a weekly sync call.

Outreach

After a reviewer has checked that research is completed without blockers, proceed to reach out to the contributor identified.

All outreach notes (date, contributors, their responses, etc.) should be added to the individual research docs.