Summary

If you set them up right, internal open-source projects can help your company gain extra development capacity and a sense of community. In this post, I discuss four key practices that help you run a successful, internal open-source project:

1. a granular backlog;

2. clear onboarding;

3. a dedicated team;

4. and a betting cadence.

“There’s nothing stronger than the heart of a volunteer.” - Kobi Yamada

I’m cynical about volunteerism at work. But my cynicism aside, communities are at the heart of many tech companies’ value propositions. Employers rely on communities and volunteers to drive many of their initiatives. Romantic as this notion may be, it’s fraught with challenges. Volunteerism isn’t for free.

1. It takes time and effort to onboard volunteers. In an efficient world, the cost of onboarding a casual contributor should be far less than the value of their contribution.

2. People are often available for short bursts of time. Few internal initiatives, however, have small pieces of precise work, so a volunteer can deliver something valuable in that short time.

3. Coordinating volunteers often stalls people who work full-time on an initiative. This hurts their throughput and productivity.

4. Several pieces of work, such as design decisions, aren’t ideal to leave to volunteers or part-timers. Such foundational work needs a dedicated core team.

5. Last but not least, there’s no guarantee that voluntary contributions will satisfy the quality requirements of an initiative. Merging contributions may take more effort from the core team than doing the work themselves.

And yet, well-intentioned leaders want their colleagues to contribute to internal initiatives casually. If done well, internal open source can help build a sense of long-term, collective ownership of a company’s digital assets. So, in today’s post, I’ll outline a framework to set up internal initiatives to accept voluntary contributions.

Think “internal open source”

The open-source world has the most successful examples of projects that accept voluntary contributions. Use that as inspiration. The above diagram is a reference for the sections that follow.

A published asset is key

Successful open-source projects have a tangible product. That’s what attracts people to contribute. A core team, sometimes just an individual, publishes the first build. Only when a product scratches a real itch do people want to contribute. 

🪧Key lesson: Publish a valuable asset first. Don’t rely on volunteers for this minimum-marketable product. Focus on adoption, discoverability and value for end users. Useful products attract the most volunteers.

Granular backlogs

Almost every open-source project tracks issues transparently and in extreme detail. Small, medium, large, they’re all there. This level of granularity helps contributors decide how they can help, depending on their available time.

🪧 Key lesson: Maintain a detailed backlog that’s open for voluntary contributions. Depending on your appetite to involve volunteers, this backlog can include small, ad-hoc work or complex tasks. Flesh out tasks in a manner that leaves no ambiguity. This is where it helps to err on the side of small tasks.😀

Clear onboarding

Look up any successful open-source project. Notice how clear their onboarding documentation is. They design their onboarding information so that a contributor can join the project in the shortest time possible. Moreover, they design their onboarding for scale. Not one. Not 10. Not 100, but thousands of contributors can onboard themselves simultaneously. This allows busy professionals to dip in and dip out when they have time.

🪧 Key lesson: Simplify the onboarding process. Document your work comprehensively and focus on the shortest path to contribution. When people can onboard themselves asynchronously, you lower the average cost of all volunteer contributions. You also free up your core team’s time from repetitive onboarding tasks. No one’s a bottleneck.

A dedicated team

The maintainers of an OSS project have the most responsibility for it. They are responsible for merging code changes and deciding the project's direction. They manage the project's issue tracker, review contributions, and maintain documentation. It’s hard to imagine a successful OSS project without its maintainers.

🪧 Key lesson: If an initiative is essential, you must staff it. Without a core team, it’s hard to establish reliable ways to accept community contributions. The core team maintains a project’s quality standards.

A betting cadence

This last part of my framework doesn’t come from the open-source world. You see, all contributions needn’t be tangible enhancements. They can also be ideas, assistance to conduct experiments, or even research. This is where a solid research prioritisation process comes in handy. Anyone should be able to propose an idea for development or even help you develop an idea. 

💡 Key takeaway: Once you get good at making research and development bets, share your execution approach with the rest of the company. When coworkers know how you prioritise such initiatives, you can encourage them to contribute their creative ideas to us in a structured format.

In summary

Here’s a summary of the dos and don’ts when setting up your internal company project to accept volunteer input.

❌ Invite volunteers to help when your program is just vapourware.

✅ Publish a valuable asset first. Make it discoverable. Help people adopt it. That’s your best chance of attracting meaningful voluntary contributions.

❌ Rely on volunteers for foundational work or work on your project's critical path.

✅ Build a backlog that’s specifically for volunteer work. Think “valuable but not urgent”. Keep it granular. Anything more than a day’s effort is too big.

❌ Let onboarding volunteers become a task that bottlenecks your core team.

✅ Write scalable, asynchronous onboarding documentation that contributors can refer to so they can work on your program independently.

❌ Hedge your entire development effort on volunteers.

✅ Maintain a core team. This is essential to ensure that voluntary contributions meet the program’s standards.

❌ Limit volunteer efforts to enhancements and improvements to assets.

✅ Invite the community to contribute pitches, do research or run experiments so you can explore the ideas to execute next.

Oh, and one more thing. Be sure to track volunteer efforts. Only when you have data about effort and results will you know how to improve your system and if you’re investing enough in your internal projects.

I’ll be honest. This framework expects programs to be at a certain state of maturity before they accept voluntary contributions. That said, you can reach this state of maturity relatively quickly. Linus Torvalds famously put out the first version of the Linux kernel in just a matter of weeks. And he was just one man. Imagine what a committed team can do!