It can be easy to identify the code contributions to an open source project. It’s much harder to identify and acknowledge the non-code contributions made to an open source project. Even with the code contributions, it’s difficult to differentiate them. This is a real problem of recognizing and expressing gratitude for all contributions in the open source community.
If I asked you how I could identify the contributors to your open source project, today, what would your answer be? Would it be the contributors file? Would it be the commit history of the repository? What about the issue tracker? Would you think of the author history in the project wiki? Would you consider the folks who consistently provide substantive answers to StackOverflow questions? What about folks who staffed a booth at OSCon this year, or gave a talk on your project at a local PyData meetup? If your project is developed within the company you work for could you point to a place I could access where the product manager is mentioned? The testing team? The devops team?
Let me ask a different question — could you identify the critical or crucial contributions in your source-code repository? Would the commit history tell the whole story? How could you identify the person who didn’t commit a lot of code, but, was the technical glue — guiding discussions, connecting efforts, and helping to find the answers to the toughest technical questions through a combination of deep technical expertise and communication skills?
This isn’t to single out the open source community; recognizing contribution is a general problem. However, the open source community is in a unique position to do something about it — we can write the software solutions to our own problems!
In many projects, the first goal is to make some new feature possible. Afterwards, you can iterate the design to make it easy. OpenTeams makes recognizing all contributions possible with the goal of making it easier and easier over time.