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 commitee member with a bunch of contributor and maintainer experience.
|
|
The value should be rated even higher than the pure business value.
|
|
|
|
## Baseline
|
|
|
|
* A öarge chunk of CNCF contrinbutors and maintainers (95%) are company affiliated
|
|
* Most (50%) of the people contributed in professional an 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 slection
|
|
* 50% of issues are labed consistentöy
|
|
* 17% of projects label PRs
|
|
* 58% of projects use milestones
|
|
* Labels provide: Context, Prioritization, Scope, State
|
|
* Milestones enable: Filtering outside of daterange
|
|
* 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 autolabel, copy label sync labels
|
|
* Prow: The label system for kubernetes projects
|
|
* People with high project but low code knowlege can triage -> Make them feel recognized
|
|
|
|
### Conclusions
|
|
|
|
* Consistent labels & milestones are critical for state analysis
|
|
* Data is the evidence needed in messaging for leadershiü
|
|
* Recruting 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, unter pressure and most of the time a one-man show that would prefer doint thechnical stuff
|
|
* CXO: Focus on ressources, health, ROI
|
|
* Product manager: Get the best project, user friendly
|
|
* Leads: Employees should meet KPIs, with slightly better techn understanding
|
|
* End user: How can tools/features help me
|
|
|
|
### Growth limits
|
|
|
|
* Main questions:
|
|
* What is theis project/feature
|
|
* Where is the roadmap
|
|
* What parts of the project are at risk?
|
|
* Problem: Wording
|
|
|
|
### Ways of surfcing 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 maintainance?
|
|
|
|
## Conclusion
|
|
|
|
* Ther is significant unrealized valze in open source
|