Product Management In Open Source

What role does Product Management and other non coding roles play within open source and GNOME? Inspired by an excellent blog post from Christian Hergert this will talk about cherishing and encouraging non coding roles within GNOME. I'll cover what Product Management is and how it can help with some of the challenges the community is facing.

Transcript

1. Product Management In Open Source
2. My Name Is Nick Richards
3. GNOME User - 20 years Contributor and Foundation Member - 10 years (off and on)
4. Flathub-ist
5. Previously seen at Desktop Summit claiming at Extensions will save us.
6. I was right! (Eventually)
7. Screenshot of ubuntu gnome
8. Moblin/MeeGo Netbook and other GNOME related items.
9. Product Manager at Endless
11. Endless OS ships a customised, forked version of GNOME shell and a plain version of the rest of the GNOME platform. Currently based on 3.26 but with plenty of activity going on upstream.
12. What is a Product Manager?
13. Christian Knows!
14. "Product managers are responsible for taking information and feedback from [everywhere] and converting that into a coherent project direction and forward looking vision. They analyze common issues, bug velocity, and features to ensure reasonable milestones that keeps the product functional as it transforms into it’s more ideal state."
15. "Most importantly, this role is leadership."
16. Read more: https://blogs.gnome.org/chergert/2017/12/11/developing-skills-with-gnome/
17. It's a role you grow into
18. Product Managers rarely start there. In the past I've been a User Advocate, Interaction Designer, Us
19. What does a product manager actually do?
20. • Tell The Story
21. • Tell The Story • Integrate all the things
22. know everything about your project, know everything about everyone's job.
23. • Tell The Story • Integrate all the things • Maintain Standards
24. Saying no in an encouraging way
25. Sounds like a free software maintainer?
26. Why should you care? You do this already
27. Christian, again
28. "For the past 3 years I’ve been working very hard because I fulfill a number of these roles for Builder. It’s exhausting and unsustainable. It contributes to burnout and hostile communication by putting too much responsibility on too few people’s shoulders."
29. Do we actually want to give up control?
30. Even if you don't, there may be some improvements
31. Which projects need Product Management?
32. Cross cutting initatives (GNOME Goals)
33. App Developer Experience Privacy
34. Areas where you need a strategic vision and co-ordination
35. "Big" projects
36. The shell, builder, anywhere where really getting close to the details makes a difference.
37. Your project may not yet have the ambition to be "Big"
38. But if you do, How do you find your vision?
39. And know if you want to be big
40. A mix of interal drive and user satisfaction
41. Q1. What feedback should you listen to?
42. Q0. How do you get feedback?
46. In person, Gitlab (or bugzilla), IRC, press reviews, blogs, forums, user testing
47. Engineering journals vs user support
48. Great products never listen in just one way
49. Apple vs Facebook
50. Endless has metrics (this is controversial)
51. Nautilus #1!
52. This also means I can tell you that Nautilus was GNOME app that Endless users opened most in the
53. GNOME has strong privacy guarantees
54. And intermediating forces (like Endless!)
55. Where possible, disintermediate
56. (this means Flatpak for apps)
57. Endless also does user research
58. and goes on the ground to talk to our users and stakeholders
59. But Product doesn't do that
60. Product is part of a software team
61. Taxonomy:
62. "Developers"
63. Interaction Designers
64. Quality Assurance
65. Tech writers
66. User Support
67. Graphic Designers
68. Security Engineers
69. Build engineers
70. Optimisation enginners
71. User and Developer Advocates
72. Hackfest Organisers
73. Product Marketers
74. Operations people
75. User Research
76. Release managers
77. Public Relations
78. Standards Committee Members
79. Infrastructure Engineers
80. Localisers
81. Internationalisers
82. Thats: Developers, Interaction Designers, Quality Assurance, User Support, Graphic Designers, Security Engineers, User and Developer Advocates, User Researchers, Tech writers, Build engineers, Operations people, Release managers, Standards Committee Members, Public Relations, Hackfest Organisers, Localisers, Internationalisers, and more...
83. Product without scale is lonely and pointless
84. Solving complex problems requires a diverse team and often doesn't admit simple solutions
85. Attracting people with skillsets you don't know about
86. 'Sit around and wait for them to do it'
87. Invite them in by name
88. Taking their tools seriously
89. Yes, that means GNOME should have a Discourse forum
90. GitLab is a great first step, not the end
91. Make sure they don't go away.
92. Doesn't mean 'do everything they say'
93. Summing up: • Everyone is making a product - you may not need management • Get a diversity of feedback - but be discerning • If you want new people you have to do something
94. Questions?