84 lines
2.7 KiB
Markdown
84 lines
2.7 KiB
Markdown
---
|
|
title: Why is this so hard! Conveying the business value of open source
|
|
weight: 3
|
|
tags:
|
|
- open source
|
|
- business
|
|
---
|
|
|
|
Bob a Program Manager at Google and Kubernetes steering committee member with a bunch of contributor and maintainer experience.
|
|
The value should be rated even higher than the pure business value.
|
|
|
|
## Baseline
|
|
|
|
* A large chunk of CNCF contributors and maintainers (95%) are company affiliated
|
|
* Most (50%) of the people contributed in professional personal time (and 30 only on work time)
|
|
* Explaining business value can be very complex
|
|
* Base question: What does this contribute to the business
|
|
|
|
## Data enablement
|
|
|
|
* Problem: Insufficient data (data collection is often an afterthought)
|
|
* Example used: Random CNCF selection
|
|
* 50% of issues are labeled consistently
|
|
* 17% of projects label PRs
|
|
* 58% of projects use milestones
|
|
* Labels provide: Context, Prioritization, Scope, State
|
|
* Milestones enable: Filtering outside date range
|
|
* Sample queries:
|
|
* How many features have been in milestone XY?
|
|
* How many bugs have been fixed in this version?
|
|
* What have I/my team worked on over time?
|
|
|
|
### Triage
|
|
|
|
* Many projects don't triage b/C
|
|
* Auth (No Role that can only edit labels+milestones)
|
|
* Thought of as overhead
|
|
* Project is too small
|
|
* Tools:
|
|
* Actions/Pipelines for auto-label, copy label sync labels
|
|
* Prow: The label system for Kubernetes projects
|
|
* People with high project, but low code knowledge can triage -> Make them feel recognized
|
|
|
|
### Conclusions
|
|
|
|
* Consistent labels & milestones are critical for state analysis
|
|
* Data is the evidence needed in messaging for leadership
|
|
* Recruiting triage-specific people and using automations streamlines the process
|
|
|
|
## Communication
|
|
|
|
### Personas
|
|
|
|
* OSS enthusiast: Knows the ecosystem and project with a knack for discussions and deep dives
|
|
* Maintainer;: A enthusiast that is tired, under pressure and most of the time a one-man show that would prefer doing technical stuff
|
|
* CXO: Focus on resources, health, ROI
|
|
* Product manager: Get the best project, user-friendly
|
|
* Leads: Employees should meet KPIs, with slightly better tech understanding
|
|
* End user: How can tools/features help me
|
|
|
|
### Growth limits
|
|
|
|
* Main questions:
|
|
* What is this project/feature
|
|
* Where is the roadmap
|
|
* What parts of the project are at risk?
|
|
* Problem: Wording
|
|
|
|
### Ways of surfacing information
|
|
|
|
* Regular project reports/blog posts
|
|
* Roadmap on website
|
|
* Project boards -> GitHub's feature for this is apparently pretty nice
|
|
|
|
### Questions by leadership
|
|
|
|
* What are we getting out? (How fast are bugs getting fixed)
|
|
* What is the criticality of the project?
|
|
* How much time is spent on maintenance?
|
|
|
|
## Conclusion
|
|
|
|
* There is significant unrealized value in open source
|