The True Cost of Open Source
•Download as PPTX, PDF•
2 likes•1,058 views
I gave this talk at the Open Source Leadership Summit 2017 (http://events.linuxfoundation.org/events/open-source-leadership-summit) Abstract: Open source projects can be extremely rewarding for both companies and participating employees, but there are associated costs that may not be immediately obvious. Engaging in public outreach, fielding community support requests at all hours, and responding to feedback and criticism are just a few examples of things that can consume maintainers and negatively affect their productivity and morale. For those on the front lines of open source maintenance, it is often more than just a day job and these associated extra hours can lead to burnout. In this talk we will examine the true cost of open source so that companies can take steps to mitigate those costs and balance their needs against the demands of open source while also encouraging a good work/life balance of its developers to ensure long-term open source program success.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to The True Cost of Open Source
Similar to The True Cost of Open Source (20)
Recently uploaded
Recently uploaded (20)
The True Cost of Open Source
- 1. The True Cost of Open Source Patrick Steele-Idem @psteeleidem
- 2. Maintaining and other projects Now leading our open source initiative Based on my experience at
- 4. Open source is easy Successful open source is hard
- 5. Open sourcing a project introduces a lot of extra work • Legal and security reviews • Marketing and branding • Public engagement • Community development and support • External bug reports and pull requests
- 6. Open source is risky • Security concerns • Reflects poorly on the company if done incorrectly • Potentially bad interactions with outside community • Employees may leave if they can take their code with them
- 7. Is it worth it? ABSOLUTELY!
- 8. Before you open source, you really need to know what you are getting into (both employer and employees)
- 9. Costs over time Time Cost Preparing Promoting Support Community We want to get down here as fast as possible!
- 10. • Personal attachment • Balancing work and open source • External criticism is taken personally • Distractions
- 11. Open source is not a one-person job!
- 13. Preparing a project for open source is costly Legal reviews, polishing the code, adding docs, removing internal references, etc. WARNING
- 14. Open source from the beginning! Build software with the mindset of “public scrutiny” Length of time kept proprietary Likelihoodofsuccess
- 15. OUR SUPPORT COSTS ARE TOO DAMN HIGH
- 16. Good documentation and extensive tests are critical Open source forces this, but you should be doing it anyway
- 17. Flexibility is not always needed Be prepared to say “no”
- 18. Breaking changes hurt Dividing your community increases your support costs WARNING
- 19. Open source projects require extra planning • Gather opinions • Keep the public API as simple as possible
- 21. If you open source a project and no one knows about it, is it really open source?
- 22. Tips for building a community ”That is a problem. Do you have any ideas on how we can improve it?"
- 23. Make source code approachable
- 24. Company should help promote projects
- 25. Hire open source contributors
- 26. You’ll be obsessed with your successful open source project Notifications, page refreshes, scouring the internet, responding, etc. TWO NEW STARS! SINCE I LAST CHECKED TWO MIN AGO WARNING
- 27. Thanks for listening! Any questions? Patrick Steele-Idem @psteeleidem
Editor's Notes
- Good morning Thank you for joining us My name is Patrick Steele-Idem Why I am here: advocate for open source Improve how companies contribute to open source Who here has maintained an open source? This talk will be from the perspective of a project maintainer. Everybody has a different experience. Every open source project is different and everyone will deal with a different set of people. This talk is based on my experience of maintaining multiple open source projects. I want to walk through the good, the bad, and the ugly. While we will be focusing on the costs, this talk is not meant to be negative or discouraging We want to reduce or eliminate unnecessary costs
- A little bit about me. I work for eBay and have been fortunate in that I have been able to work almost exclusively on open source for the past 5 years. This year I will be leading an initiative to improve how we do open source at eBay I spend a lot of time maintaining open source projects such as Marko Describe Marko Marko is part of the Node.js ecosystem. Node.js has wonderful community that encourages collaboration and open source contributions. We have over 50 contributors at this point, and a large percentage of this contributors are from outside eBay. It took a long time to get to this point I learned a lot Changing culture with more emphasis on collaboration. Rewarding but a lot of work This work has a direct impact on maintainers, the company and the success of open source projects
- Open source dominates the platforms that power most technology companies We all know these benefits (otherwise we wouldn’t be here) Open source is great for these companies When building something in open source manner you are forced to consider outside use cases to promote outside adoption. This is a good GIving back and changing how we build, deploy and run software Done correctly, contributing to open source can be a huge win for a company Done poorly, it can be detrimental
- It may seem simple but it is not More than filling out checkboxes More than dumping code into a public Github repo Extensive follow through and and considerable resources are required As the number of open source projects increases, so does the work There are hidden costs that may not be immediately obvious If not managed properly: Derail the success Or worse, deter future open source participation by the company
- Significant amount of extra work required at all levels Some of these costs may be obvious Other work might not become apparent until much later. It’s important that management understands upfront what’s required: Open source projects stay healthy Developers don’t feel abandoned after the initial release of an open source project.
- With that said, I think it is important that everyone understands all that is involved and potential problems that you might face along the way.
- In my experience, open source software has very high upfront costs Costs go down over time if done correctly. At the beginning there will be a lot of time preparing for the initial open source release You’ll then spend time promoting the project. If your project starts to get noticed then you will need to spend even more time: Answering questions Responding to bug reports and feature requests Reviewing Pull Requests Hopefully these things will be helpful, but I think you will find that a lot of these requests won’t align with the project vision. Unfortunately you can’t simply ignore these requests. If the community does not feel engaged then they will likely move on. During the first three stages of open source, most of the burden will be on the company. It’s not until the community starts to develop will you start to see the support costs go down. At the beginning, a lot of time spent is spent preparing and promoting the project, so at this point, the burden is mostly on the company. And as we discussed, even after the project is put out there, more developer time is needed to answer questions from those that are just learning about the project.*** Then the bug reports and feature requests start coming in. Many of them (?) won’t be valid or don’t align with the project vision, but they require time to address. But assuming these things (which things?) were handled correctly and assuming the project has merit then a community will start to develop. You’ll start to see the outside community helping other members, contributing bug fixes, and working on improvements. Suddenly project support becomes a shared burden versus one that is exclusively borne by the company, and it feels awesome. So needless to say, we want to get to that state as early as possible ( and I’ll be giving you some tips on that in just a moment.)
- DO NOT TALK SOLUTIONS Let’s first talk about the developers and maintainers behind open source projects These are are the folks who clearly bear the brunt of the extra work involved in open source programs. Open source projects are a reflection on both the company and the individual maintainers. While an open source project is seen as part of a company, most developers will feel that an open source project is a direct reflection of themselves. A maintainer will be extremely motivated if the project is successful, but the maintainer of an open source project that is not well received might feel like a failure. Contributing to open source is likely more than a 9-5 job While a company might expect a developer to move on to other tasks after a project’s initial release, it’s likely that an open source project will continue to consume lots of that developer’s time and energy. After all, someone has to respond to bug reports and questions that crop up and it’s unlikely that a developer will simply ignore online praise or criticism without taking the time to engage, advocate, and/ or defend that developer’s project in the online community. It’s extremely important that a company gives clear public and internal commitment to its open source projects in order to support its developers. Otherwise, there is a risk of developer burnout and you I’m sure you all know how important it is to avoid the loss of talent in today’s competitive tech industry.
- Earlier on, I made the mistake on taking on open source projects all by myself. While I had the support of my company and the support of many developers, in the end, I was left feeling burnt out and the projects I maintained still didn’t get the traction I had hoped for. The problem was there was no way I could support the community while still making improvements to the project. On top of that, I didn’t have a person that I could rely on for bouncing ideas off or figuring the technical direction. I believe any reasonably complex open source project requires at least two core maintainers. This is the minimum number and with success you will find additional outside maintainers to add to the project.
- There are things that a company can do to promote collaboration on an open source project. Don’t underestimate the importance of collaboration tools. Embracing the right tools can make a huge difference. For my projects we use a Gitter for all public discussions. We use Slack for all internal discussions. While we have channels for internal discussions, we strongly encourage all communications to go through public channels for improved transparency. Screenhero has been an EXCELLENT tool for helping the community. Emails should be avoided. Github issues are MUCH better. Beyond tooling, it’s extremely important to develop a culture of collaboration
- Approvals Legal reviews Security reviews References to internal systems Polishing the docs Adding tests Branding Changing the names of artifacts ”The internal name you picked won’t work for the open source project” Adding licenses DO NOT TALK SOLUTIONS
- If you are getting the same question over and over then you have done something wrong. If you are afraid to make changes then you don’t have enough tests. When you break something you will feel awful. You also lose credibility. If people see the project as fragile it is unlikely to be recommended
- Isaac, the maintainer of npm, once said maintaining open source projects is like having children. I’m paraphrasing here, but maintaining open source will start out feeling like a lot of pointless busy-work and you might wonder ”why would anyone do this?” Suddenly you will fall in love with it and before you know it you’ll end up with 3 or 4 more. It’s a lot of work, but it’s absolutely worth it. The positive feedback loop from maintaining an open source project is extremely rewarding. I want to give a huge thanks to all of the companies and foundations that support open source projects. You never know how an open source project will turn out and takes some risk to participate. I hope the investment is worth it. Also, I want to give a huge thanks to other project maintainers and non-passive community members.