Incentives power open source
In the recent Tidelift crystal ball for open source security webinar, one of the panelists noted that getting open source developers to meet supply chain requirements requires giving them an incentive. They pointed out that right now, the incentives are all on the companies consuming the project. My immediate reaction was “everything you want people to do in an open source community requires some kind of incentive.” This isn’t a novel thought by any stretch of the imagination. The challenge is that the same incentives don’t work for everyone.
The incentives for contributing to an open source project are as diverse as the people who contribute. Some are scratching their own itch: fixing a bug or adding a feature that affects them. Others are giving back to thank the community for the software it provides. Some people are learning new skills or adding to their résumé. Sometimes people want the social connection of being in a community. T-shirts and stickers are known to be powerful motivators for some people. Others say “show me the money”; they’re only contributing because they’re being paid to.
None of those incentives are wrong. The problem comes when the offered incentives don’t match what the contributors want. Context matters here, too. If a volunteer or donation-funded maintainer offers some stickers as a thank you for a contribution, that comes across much differently than when a multi-billion dollar company does. One feels like a sincere token of appreciation, the other feels cheap.
The best approach is to have a menu of incentives that you can offer. This way, you can attract people with different motivators and expand your pool of contributions. Of course, the specific incentives you can offer will depend on the money and resources you have available. But if you’re working for a company that is trying to incentivize work, you need to include budget for meaningful incentives in the plan.
You also need to be clear about what the incentives are and why they might be valuable. There’s almost always more than one benefit. While “we need this upstream project to be more secure to make our customers more secure” is a perfectly reasonable thing for a company to say, it’s not the whole story. Returning to the idea that the incentives are entirely for the company making the requests (demands?), I don’t think that’s true. But the company making the demands has to explain the incentives in a way the project members will care, not in a way the company cares.
This post’s featured photo by krakenimages on Unsplash.
