Partnerships are two way relationships. Care and feeding of a partnership is critical. It is important to understand what your partner expects from the relationship. If we take the relationship seriously, then our partners will also take our involvement seriously. The very short version, we have to give respect, in order to get respect.
This attitude towards open source as a partner is very important to instill in your engineers. They are the shock troops of your effort to make or break the use of open source in your organization. Your devOps engineers will need to understand that their ideas and code are appreciated, but what an open source project really needs is someone that will dig in and solve existing problems, not create new ones. Show up ready to work. Put some time in and then bless the team with your new ideas. Work you do is not only code. It can be running user user groups, updating documentation, or training new users.
Meritocracy. OpenStack lives and breathes it. Your value is equal to the amount of work you do. Period. End of story.
So you want to get involved. Participate in OpenStack. You should start here at this wiki page. https://wiki.openstack.org/wiki/How_To_Contribute. This page is great, but it’s missing the sitemap feel. Where is the quick start? I started this wiki page as a table of OpenStack Participation rights, responsibilities, and restrictions. It’s a rough draft, so feel free to fix mistakes. I’m working with the OpenStack Foundation staff to incorporate more of this into teaching OpenStack members all the information in the table.
Brainstorming more your thing? I started a mindmap of OpenStack Participation as well.
I’ll continue to discuss meritocracy, participation, and partnerships in future posts (rants).
### 20:00 PDT 11 March 2014 updated to clarify the definition of work based on feedback from Joshua McKenty ###
