Open source software is great for developers. It lets you see the internals of framework or app, and know how to best interact with it. On top of this, we can also submit code to be included, and comment on code the core maintainers are submitting. Getting developers not normally engaged in the process, to become a contributor, is actually harder than it seems. It is never as simple as just submitting code.
Xamarin.Forms Sprint
From my recent [POLL] What CustomRenderers Or Effects Do You Create In Xamarin.Forms?, I highlighted many parts of the Xamarin.Forms framework that developers wanted upgraded. While we could submit the list to Xamarin, and hope, they did suggest that the community could get behind it and do it themselves. So we did, and we have submitted quite a few pull requests.
If you want to read more into that story, you can check out Xamarin.Forms Monthly Newsletter – Issue #22.
But nearing the end of this sprint of work, I wanted to share what I learnt observing and helping organize this sprint.
Core Team Has To Lead
The core maintainers are ultimately those that decide if they want to accept a PR, hence they should be the ones who lead the charge. My recommendation to a core team that wants help, is to:
- Get a list of issues, by creating a poll or similar means. Listen to the community.
- Work through this list, and see what is a good candidate for community assistance, and what you will accept.
- Create proposals (e.g. in GitHub Issues) for how they will be done, the more detail the better.
- Then set a date for when you want to run the sprint to and from.
On-boarding Process
Next, you want to create an on-boarding process. This is similar to starting a new job, except they aren’t getting paid, so the tolerance for difficultly is really low.
- Establish a Slack Channel or other way for direct communication. I tend to keep these invite only, as to not flood the channel with many people who aren’t that interested.
- Write an FAQ
- Coding Styles
- How do I obsolete APIs?
- How to pick an Issue to work on
- How your PR process works. Rebasing, branching, forks, etc.
- Checklist before they submit a PR. This may include updating docs, adding unit tests.
- Detail how you test code. Do you have a sample project in your app, that you use. Where do you do UnitTests. Do you do other tests such as UITests?
- Direct them to the issues list, and let them get picking.
Setting Up A Sprint
I am firmly for setting up a fixed period for each sprint. You also don’t need to do a sprint one after the other, you could just host a few per year.
- Set a time limit. People have jobs, family commitments and aren’t going to be using 100% of their free time to forever support your project. While traditional sprints last for 2 weeks, 1 month seems more appropriate here, to give people time to work on it, on and off.
- Keeping a time-limit will also help people decide if they want to commit, as they know its only for a short time.
- When you have a number of developers ready for a sprint, assume 1/3 aren’t going to do anything. Then estimate how many issues you think this remaining group can tackle, and then reduce that list down to 1/3. That is realistically what is going to be done.
- Have a way to assign issues to developers. In this sprint, we had people comment on the Github issue, then it would be assigned to one of the Core Maintainers to show it was taken. However this has a lot of issues in keeping track of where everyone is up to and what they are working on, without someone updating it.
Motivation
Developers want to contribute to OSS for numerous reasons.
- Excitement of contributing on a well-known project and knowing that many developers around the world will use your code.
- Learning something new, from more experienced developers
- Fixing a problem they wanted solved.
But this excitement level drops very quickly. Remember, no one is getting paid here and the most you get at the end of contributing is a self pat on the back, maybe a few thank you’s, and you possibly solved your own problem. If you wonder why people’s don’t stick with it, this is generally why. They have their family time, relaxation time, or work to deal with, and they are all far more important than contributing to an open source project.
With this in mind, don’t expect too much from contributors. They might just join in one sprint, some might come back and submit randomly here and there from now on, when they want to fix something or have spare time.
Summary
With all of that in mind, just keep communication and assistance open, and you will see some excitement and contributions come your way.
Open Source software, backed by an organization or solid core contributor base, is well suited to do this. The lack of money in maintaining open source software is a major concern. Personally I think that if corporations that used a lot of open source software, dedicated some time for their developers to contribute back to the source, we could help bolster the open source community and also help train developers to become better in some of the frameworks they use. The developers contributing are then also getting paid, which will help them keep focus and quality.
I have also found that developers are sometimes very eager to contribute to open source, but have no idea where to start. Hence core maintainer’s setting up sprint events, even if only a few per year, are the perfect introduction to helping new contributors on board and communicating with each other. They will then likely contribute outside of sprint cycles, when they have time to.
Cross platform mobile developer who loves delving deep into frameworks and solving problems.