In OpenStack, all our coding is done out in the open. You can read the source code and follow the peer reviews the code went through before it was merged in. Often times, however, the original intent behind a blueprint or feature request gets murky, leaving code reviewers focused on the trees instead of the forest. In this talk, join Brian Rosmaita, Cloud Images Product Manager at Rackspace, as he advocates for full features documented with use cases, prototype press releases, and preliminary FAQ lists to help articulate the vision for features. Brian will share his experiences in working in the Glance project, and offer practical advice on how developers and product managers can work together to improve the overall experience of turning OpenStack ideas into products.
http://sched.co/1dJ5rrM
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
Product Development in the Open - OpenStack Summit May 2014 Atlanta
1. (open source isn’t just a developers’ thing)
Product Development in the Open
2. #rackstackatl
• Brian Rosmaita
– @br14nr
– IRC: rosmaita
• Cloud Images Product Manager at
Rackspace
• OpenStack ATC since Folsom
– Mostly Glance and docs
• Glance driver
• Happy to be here, hope you’re
enjoying the summit
About me
3. #rackstackatl
• Who cares about OpenStack?
• Open source code development vs. product development
• Why product development is important for open source
• Product development in the open
• What you can do
Outline
4. #rackstackatl
• Who cares about OpenStack?
• Open source code development vs. product development
• Why product development is important for open source
• Product development in the open
• What you can do
• What you should do
Outline
5. #rackstackatl
• Who cares about OpenStack?
• Open source code development vs. product development
• Why product development is important for open source
• Product development in the open
• What you can do
• What you should do
• What you must do
Outline
8. #rackstackatl
• Do end-users care about OpenStack?
– I hate to say this, but probably not
Who cares about OpenStack?
9. #rackstackatl
• Do end-users care about OpenStack?
– I hate to say this, but probably not
• Do end-users care about open source?
Who cares about OpenStack?
10. #rackstackatl
• Do end-users care about OpenStack?
– I hate to say this, but probably not
• Do end-users care about open source?
– Probably not
Who cares about OpenStack?
11. #rackstackatl
• Do end-users care about OpenStack?
– I hate to say this, but probably not
• Do end-users care about open source?
– Probably not
• Can we just ignore them?
Who cares about OpenStack?
12. #rackstackatl
• Do end-users care about OpenStack?
– I hate to say this, but probably not
• Do end-users care about open source?
– Probably not
• Can we just ignore them?
– Probably not
Who cares about OpenStack?
13. #rackstackatl
• Do end-users care about OpenStack?
– I hate to say this, but probably not
• Do end-users care about open source?
– Probably not
• Can we just ignore them?
– Probably not
– If you’re running a public cloud: definitely not
Who cares about OpenStack?
14. #rackstackatl
• Do end-users care about OpenStack?
– I hate to say this, but probably not
• Do end-users care about open source?
– Probably not
• Can we just ignore them?
– Probably not
– If you’re running a public cloud: definitely not
– If you’re running a private cloud: the “shadow IT” phenomenon
Who cares about OpenStack?
16. #rackstackatl
• Do providers care about OpenStack?
– I think current and potential cloud providers care about open-source
Who cares about OpenStack?
17. #rackstackatl
• Do providers care about OpenStack?
– I think current and potential cloud providers care about open-source
• Providers want
– Stability
Who cares about OpenStack?
18. #rackstackatl
• Do providers care about OpenStack?
– I think current and potential cloud providers care about open-source
• Providers want
– Stability
– Ongoing improvement
Who cares about OpenStack?
19. #rackstackatl
• Do providers care about OpenStack?
– I think current and potential cloud providers care about open-source
• Providers want
– Stability
– Ongoing improvement
– Stability
Who cares about OpenStack?
20. #rackstackatl
• Do providers care about OpenStack?
– I think current and potential cloud providers care about open-source
• Providers want
– Stability
– Ongoing improvement
– Stability
– Competitive features for end users
Who cares about OpenStack?
21. #rackstackatl
• Do providers care about OpenStack?
– I think current and potential cloud providers care about open-source
• Providers want
– Stability
– Ongoing improvement
– Stability
– Competitive features for end users
– Stability
Who cares about OpenStack?
22. #rackstackatl
• If your customer base primarily interacts with a control panel, you can swap out
the control plane and customers might not even notice
Who cares about OpenStack?
2
23. #rackstackatl
• If your customer base primarily interacts with a control panel, you can swap out
the control plane and customers might not even notice
• Or you could switch to different cloud software that has a compatible API and
customers might not even notice
Who cares about OpenStack?
24. #rackstackatl
• If your customer base primarily interacts with a control panel, you can swap out
the control plane and customers might not even notice
• Or you could switch to different cloud software that has a compatible API and
customers might not even notice
It’s a jungle out there!
Who cares about OpenStack?
30. #rackstackatl
• Am I committed to OpenStack?
– What I’m committed to is the ongoing shared project of developing excellent open-source
cloud software
Who cares about OpenStack?
31. #rackstackatl
• Am I committed to OpenStack?
– What I’m committed to is the ongoing shared project of developing excellent open-source
cloud software
– OpenStack is the best game in town
Who cares about OpenStack?
32. #rackstackatl
• Am I committed to OpenStack?
– What I’m committed to is the ongoing shared project of developing excellent open-source
cloud software
– OpenStack is the best game in town
• “ongoing shared project” == the community
Who cares about OpenStack?
33. #rackstackatl
• Am I committed to OpenStack?
– What I’m committed to is the ongoing shared project of developing excellent open-source
cloud software
– OpenStack is the best game in town
• “ongoing shared project” == the community
Who cares about OpenStack?
TRUST + CONTRIBUTION
35. #rackstackatl
• The community isn’t something to observe …
• … it’s something to participate in
The OpenStack community
TRUST + CONTRIBUTION
36. #rackstackatl
• The community isn’t something to observe …
• … it’s something to participate in
• The community requires constant care and nurturing if it’s to remain the vibrant
and exciting entity it is today
The OpenStack community
TRUST + CONTRIBUTION
37. #rackstackatl
• What am I going to do with OpenStack?
The OpenStack community
TRUST + CONTRIBUTION
38. #rackstackatl
• What am I going to do with OpenStack?
• What am I going to do with OpenStack?
The OpenStack community
TRUST + CONTRIBUTION
42. #rackstackatl
• Coding is done in the open
• Anyone – cloud provider, ops team, developers, end-users, random passers-by
– Can read the source code
– Can see the peer reviews
– Can see the history of code development
Open source code development
43. #rackstackatl
• Coding is done in the open
• Anyone – cloud provider, ops team, developers, end-users, random passers-by
– Can read the source code
– Can see the peer reviews
– Can see the history of code development
– Can look up the history of the ideas behind this piece of code
Open source code development
44. #rackstackatl
• Coding is done in the open
• Anyone – cloud provider, ops team, developers, end-users, random passers-by
– Can read the source code
– Can see the peer reviews
– Can see the history of code development
– Can look up the history of the ideas behind this piece of code
• Mailing list archives
Open source code development
45. #rackstackatl
• Coding is done in the open
• Anyone – cloud provider, ops team, developers, end-users, random passers-by
– Can read the source code
– Can see the peer reviews
– Can see the history of code development
– Can look up the history of the ideas behind this piece of code
• Mailing list archives
• IRC meeting logs
Open source code development
46. #rackstackatl
• Coding is done in the open
• Anyone – cloud provider, ops team, developers, end-users, random passers-by
– Can read the source code
– Can see the peer reviews
– Can see the history of code development
– Can look up the history of the ideas behind this piece of code
• Mailing list archives
• IRC meeting logs
–“official” IRC meeting channels
» #openstack-meeting , #openstack-meeting-alt
Open source code development
47. #rackstackatl
• Coding is done in the open
• Anyone – cloud provider, ops team, developers, end-users, random passers-by
– Can read the source code
– Can see the peer reviews
– Can see the history of code development
– Can look up the history of the ideas behind this piece of code
• Mailing list archives
• IRC meeting logs
–“official” IRC meeting channels
» #openstack-meeting , #openstack-meeting-alt
–Project-specific meeting channels
»E.g., #openstack-glance
Open source code development
48. #rackstackatl
• The history of the ideas behind a piece of code is important when reviewing it
Open source code archaeology
49. #rackstackatl
• The history of the ideas behind a piece of code is important when reviewing it
• This code is acceptable because:
– It has no obvious flaws
– It doesn’t break compatibility with other parts of the code
Open source code archaeology
50. #rackstackatl
• The history of the ideas behind a piece of code is important when reviewing it
• This code is acceptable because:
– It has no obvious flaws
– It doesn’t break compatibility with other parts of the code
– It implements the feature correctly
Open source code archaeology
51. #rackstackatl
• The history of the ideas behind a piece of code is important when reviewing it
• This code is acceptable because:
– It has no obvious flaws
– It doesn’t break compatibility with other parts of the code
– It implements the feature correctly
– … and if there’s a migration path, it’s well thought-out
Open source code archaeology
52. #rackstackatl
• It would be good if the archaeology were not so “archaeological”
Open source code archaeology
55. #rackstackatl
• OpenStack has two customer segments:
– Deployers (consumers of OpenStack software)
– End-users (consumers of cloud services)
Modern product development
57. #rackstackatl
• Software development goes better when developers understand:
– The purpose of the feature they’re developing
– How it fits into the Big Picture
– That it will actually be used
Modern software development
58. #rackstackatl
• Software development goes better when developers understand:
– The purpose of the feature they’re developing
– How it fits into the Big Picture
– That it will actually be used
• And, of course, code reviews can be more meaningful when these things are
understood
Modern software development
62. #rackstackatl
• Product-type people have a skill set that can make a serious contribution to the
community
• We can decrease the necessary amount of “archaeology” by treating
OpenStack code development as part of product development
Product development in the open
63. #rackstackatl
• Product-type people have a skill set that can make a serious contribution to the
community
• We can decrease the necessary amount of “archaeology” by treating
OpenStack code development as part of product development
• … rather than as an artifact around which to build a product
Product development in the open
64. #rackstackatl
• Product-types have a skill set that can make a serious contribution to the
community
• We can decrease the necessary amount of “archaeology” by treating
OpenStack code development as part of product development
• … rather than as an artifact around which to build a product
• Increase
– Developer satisfaction
– Deployer awareness
– Documentation readiness
Product development in the open
65. #rackstackatl
• Product-types have a skill set that can make a serious contribution to the
community
• We can decrease the necessary amount of “archaeology” by treating
OpenStack code development as part of product development
• … rather than as an artifact around which to build a product
• Increase
– Developer satisfaction
– Deployer awareness
– Documentation readiness
– User delight!
Product development in the open
70. #rackstackatl
• Press release before the product is built
• FAQ before the product is built
• Documented use cases
What you can do
71. #rackstackatl
• Press release before the product is built
• FAQ before the product is built
• Documented use cases
• Customer validation
What you can do
72. #rackstackatl
• Press release before the product is built
• FAQ before the product is built
• Documented use cases
• Customer validation
• and …
What you can do
74. #rackstackatl
• OpenStack is more than code
• Community is key
• Product-type people can contribute to OpenStack
Take-aways
75. #rackstackatl
• OpenStack is more than code
• Community is key
• Product-type people can contribute to OpenStack
• Product-type people should contribute to OpenStack
Take-aways
76. #rackstackatl
• OpenStack is more than code
• Community is key
• Product-type people can contribute to OpenStack
• Product-type people should contribute to OpenStack
• Product-type people must contribute to OpenStack
Take-aways
78. #rackstackatl
• I just wanted to address a few questions that came up
– The example docs are in their final state.
• What you don’t see is that there were several revisions as the discussion developed on the mailing list
and in IRC meetings.
• Keep in mind the “archaeology” metaphor—the point of the “product” docs is to record community
consensus, not to impose a particular view or to deliver a pre-designed API.
• You want to document the consensus enough so that a core reviewer can look them over and
understand whether or not the code being reviewed meets the consensus requirements for the feature.
– Have a thick skin
• Expect to see eyes roll (or whatever the IRC equivalent is) when you first start participating in IRC
meetings and design discussions.
• Some developers are more receptive to this kind of help than others. It may take some time to earn
trust, don’t get discouraged.
Postscript