Dr. Dawn Foster is a unix sysadmin for VMware, did her doctorate on linux kernel development and has been following her tech career for over twenty years! Her main focus is community and open source work. In her talk she enlightened us about how to be a Good Corporate Citizen. If you would prefer to watch a recording head on over to YouTube to listen to her talk – or if you prefer to read all about it, go ahead and read on!
This is what I’ve learned from Dawn in her talk “How to Be a Good Corporate Citizen in Open Source“:
Collaboration in OSS Projects: Individuals, Companies, Communities
Open source communities have a variety of different people involved.
A project has developers, a release team, localisation and translation teams, marketing, community managers, tech writers, users and lots of other people involved. All of these people are working together as one community towards the goal of a good project.
Balance
This community that works on the project is what makes the decisions on where the project goes, an outside corporate entity can not force them to adapt changes they don’t want – or that go against the direction of the project. As a company, you need to align your needs with the needs of the project. This is important to understand when making contributions, so you don’t put your employees in a position where they have to either do harm to the project or their employment.
Contribution Strategy and Plans
Aligning Goals
The first and most important step is to make sure that your companies and the project’s goal are in alignment. If this is the case, it will be so much easier to justify putting resources and effort into the project. It also makes it easier to make the team that works on the project understand the importance of their work.
Finding and focusing on projects is an important point. Look at your operations team and what tools they use – those might be a great fit to support. Are there development or deployment tools that are open source and you could support? These questions can help you figure out what to support, in order to make a better point to your superiors to help support those projects.
Communication
Make sure that all of your teams that work on open source projects communicate with each other, to avoid having conflicts in public open source projects. If your vision is aligned, you will have a lot fewer issues. You can even help organise meetups, provide discussion channels and events to further help foster productive discourse.
Which Projects?
After you know which projects to support, you need people to contribute. Maybe you already have people that have contributed in the past. Keep in mind that contributing to open source projects needs a different skill set than working on internal projects – they need to for example be comfortable receiving and reacting to feedback in public.
Staffing
You can also hire people that are already contributing to those projects – but you might need to be careful with that, because you do not want to get the reputation to aggressively poach contributors from projects. It requires a bit of nuance to make it known that you are hiring for a project, without coming across too strong.
Guidelines
Having guidelines and best practices ready for people to engage in open source projects. Try to find a good balance between providing help and guidance and not being too overbearing or scaring your employees away from making contributions. Help engineers understand what they want to do and why.
Measure Success
You also want to make sure you can measure outcomes and results. How do you pull that kind of data? It really depends on what you want to achieve – examples would be: for the goal “improving performance” check the softwares performance data. For the goal “gain influence” check your employees in meaningful positions in the project. You might also want to overmeasure a little bit, to have some extra data at hand, in case your focus shifts in the future.
Making Contributions as a Good Corporate Citizen in OSS
Before hopping into a new project, you might want to look around a little and understand how the community works and feel around a little. Look at the documentation, especially at the contribution docs and the code of conduct. All projects work differently and understanding how things work to not violate any community norms.
Start with small contributions and work your way up, instead of just working on a big addition to the project and just dumping them unannounced.
Learn from Feedback
When you start participating in a project you need to expect feedback. Sometimes feedback will be kind, sometimes it will be worded a bit more harshly. What you need to do is stay focused on what changes you need to make on your contribution, stay kind and maybe have someone proofread what you write to catch any unwanted harshness in how you write your answers. Try not getting defensive and iterate on what you mean.
Work with the Community
You might want to connect with people that worked on similar areas that you are touching on, and collaborate. Get in touch with the people who run a project and discuss strategies with them, to offer better help and be more productive in the process!
Break up your work into smaller contributions to make it easier for the maintainers to work with you and to iterate through the process.
Remember that you have a lot less control over other people working on the project, unlike in a company where you are able to escalate issues to managers. Meet people where they are and be kind!
Relationships
Having good relationships with people you collaborate with makes it a lot more easy and fun to work together. Conferences and meetups are very important to solve issues when you can talk about something in person. Knowing the human being behind the other side of your screen can make a big difference! When you need to do something new, or have questions – having someone you know that can put you in the right direction is an incredibly valuable thing to have.
Upstream your Patches
When you maintain your patches internally, every time the project has an update there is a risk that someone will forget to apply them, or has to fix places that were touched by the upstream and the patch. If you get your patches in the upstream repository you will not run into those issues and you might help other people with them as well!
Maintenance Expectations
If you are adding larger features to a project’s codebase, make sure that you can help with its maintenance and have someone constantly assigned to that task. If you make additions to a project and then bail on it, you create a big workload for the maintainers, which will make you and your organisation look bad and future contributions to this or other projects will be a lot less well received.
Open Source Your Software
If you are open sourcing your projects, don’t just dump dead projects onto the internet and hope someone is going to take over. This is at best naive, and will also make your company look bad. Take care of your software, just the same way you would under a proprietary licence!
Maintaining a project with the community involved is a lot of work, but it pays off in the long run. Tend to your pull requests and issues and you will reap the hard work others have put into it.
If you have read through this all, you’ll be happy to hear that there is more content like this on this blog – or if you also enjoy a video about it, check out our YouTube channel with lots of recordings from our conferences!
Take a look at our conference website to learn more about stackconf, check out the archives and register for our newsletter to stay tuned!
0 Comments