[go: up one dir, main page]
Skip to content

Problem validation: Upstream OSS contribution requires break in workflow and multiple tool use

Problem Statement

Contributing to upstream OSS projects requires I use multiple tools and breaks my workflow in GitLab.

Reach

1.5 = Small reach (~5% to ~25%)

While there are a large number of consumers of OSS projects, the number of companies that contribute back to said projects is minimal, as low as 20% (source).

To further breakdown this data:

  • Roughly 80% of all developers state they contribute to OSS (source).

  • 28% of companies contribute to OSS projects (source).

  • Our current FREE MAU (link) is 1,981,000. Assuming 80% will contribute to OSS, reach would be 1,584,800

  • Our current PAID MAU (link) is 599,000. Assuming 20% will contribute to OSS, reach would be 167,720.

  • Combined user reach total = 1,752,520. Out of a total 4.82m active users (source), reach sits at 36%

Impact

2.0 = High impact

This will make it easier for users to contribute back upstream to GitHub. This increased efficiency will decrease developer hours when contributing to OSS projects. There is also an upside for security-minded orgs who may not open access to the entire internet to have this feature, but it's a small cohort.

While this may not generate additional revenue, it will position GitLab as a collaboration leader; recognizing that GitHub continues to be the home for OSS and making it easier to contribute upstream (akin to recognizing the ubiquity of Jira and making it easier to integrate). This would have a very positive impact to the brand and company.

Confidence

50% = Low confidence

The problem is apparent on a small number of companies, which themselves tend to be large, compliance-minded orgs. (ie financial institutions). While the problem may be prevalent there, we would have to confirm it is more pervasive.

The workflow proposed may not take into account some the compliance and governance rules that these types of orgs may have in place. Some may prove too complex to make it worth solving. Additionally, air-gapped instances may not allow two-way communication with GitLab.

To increase confidence, we can conduct research with teams that contribute back to OSS, specifically to learn about existing workflows for this. Also research with teams that want to contribute to OSS but currently don't do so.

Effort

6 months

An MVC that at a minimum replicates MR in GitLab to PR in Github would be required to make this useful. There are many aspects to consider and solve for, such as synchronization, pull/push status, resolving conflicts, etc.

Edited by Daniel Gruesso