Principle #7 – Keep Your Team Informed
Communication is the key to any operation. In the Army, they taught that an Infantry Soldier needs to do three things in order to succeed: Shoot, move, and communicate. Well, there should be very little gun fire in open source development, so shooting is less essential. Movement to, since most things happen via network. But communication is paramount. Tell people what you are going to do. A great decision left not communicated is no decision. In the absence of information, people will make assumptions. It is easier to correct mistakes early, and to identify them requires review and correction.
You might not know everything that people want to know. Tell them that. Maybe you don’t have a release schedule. Knowing that there is no fixed release schedule is better than wondering when the release is going to come.
Maybe you haven’t had time to review a patch. Let the submitter know that, and you will get to it when you can. In that exchange, you might learn that it really is not a high priority issue, and you can prioritize down.
Principle #8 – Develop A Sense of Responsibility In Your Team
Tough to do this, but straightforward. Set the example. Show the people that are involved with your project that you believe in it. Some will stick, some will not. The ones that do will do so for varied reasons. But not all will have the bigger picture.
Free and Open Source Software (FOSS) carries with it a built in sense of ownership, and a corresponding responsibility. Once you realize that you “can” fix something, you often feel you “should.” The trick is to get people to “do.” This means inspiring them to do so. Respectful communication is key. Go back and reread “Schofield’s Definition of Discipline.”
A sense of responsibility means that they learn the full software development life cycle. Just finishing a feature is the starting point; it needs to be tested, documented, and released, and all these things require effort as well. They are not “fun” and they can be grinding. If a patch conflicts with another patch, it has to be rebased and deconflicted, often manually. This can be frustrating as well. Only if a team member “owns” the patch will they be willing to put in the effort to see it through.
A trickier aspect is to get a developer from an organization with a particular perspective to understand demands from other organizations. We’ve seen this a lot in Open Stack. I work for a company that distributes software that other companies need to install. OpenStack is a product to me. My customers have a particular set of demands. I work very closely with people from other companies that have large, public clouds. Open Stack is something that they deploy, often right out of the upstream repository, to a limited set of deployments. It is a key part of their revenue model, and if it breaks, they suffer. Both perspectives are important, and can be complementary. Features built for one model can often be critical to the other model….once they are understood. You have to be responsible to all of the downstream deployers of your project, not just the ones that pay your paycheck, or the project suffers.
Principle #9 – Ensure Each Task is Understood, Supervised and Accomplished
Not everyone gets to do the fun stuff. But sometimes, people don’t even realize what needs to be done to get a project done. Writing the code that gets executed at run time is the focus, but there is all the other stuff: packing and install scripting, start up and cleanup, Database management, and automated QA. People need to write unit tests to go along with their features. All of this stuff is important, and as the project leader, you have to make sure it happens. For a small project, you may do it all. However, as some noted Linus doesn’t scale. The Linux kernel has a strong delegation culture, and a slew of companies that fill in the gaps to make sure that aspects of the Kernel are solid.
A bug tracker is key. I am a fan of the approach where everything goes in the bug tracker as it minimizes the number of systems to check. Bug trackers are not the best for submitting code patches, though, and so linking the patch submission process to bugs is essential. We’ve been using Gerrit on OpenStack and it is a fairly successful approach. FreeIPA does everything on the mailing list, which also works, so long as you periodically comb the list to cross reference submitted versus merged changes. The larger the project, the more essential it is to automate the tracking process.
Now, not every bug is going to get fixed in every release, and not every feature will be implemented. Prioritize and select among them, and make sure the most essential efforts get priority. It is OK to postpone a feature to the next release, and then the one after that if the priority is just not there; often, you find a key feature emerges that obviates an old approach.
The hardest thing to do is to tell someone that the patch that they have put a lot of effort in to writing is not acceptable. This is often due to the need for testing, or because the patch is going in the wrong direction. If this happens, make sure you approach the developer with the respect due and explain clearly why you are chosing not to include their patch. Keep an open mind: often today’s bad approach is, in retrospect, what you wish you had done a year from now. Keep the code around and retrievable, but understand that each submission has its cost. Just adding code to a project may increase the load on testing, docs, and deployment, and you have to justify that effort. If you are going to perform a task, you need to ensure all the specified and implied tasks that surround it are accomplished, too.