News
Firms Explain How To Overcome Open Source Development Challenges
- By David Ramel
- June 3, 2016
Who better to explain how to overcome the challenges of managing open source projects and cultures than open source champions Red Hat Inc. and Docker Inc., both of which have come out with brand-new resources detailing their in-house processes and best practices for community software development?
Within days of each other, Red Hat open sourced a best practices tool for managing open source projects, while Docker continued its blog series on how it does the same, this week focusing on its internal processes, such as how it promotes contributing developers to maintainer status.
Here's a look at what each company is doing.
Red Hat Inc.'s Open Decision Framework
"For the past few years at Red Hat, we've been grappling with the challenges of growing an open organization and sustaining our culture along the way," Red Hat's Rebecca Fernandez said in a blog post Wednesday. "One tool we've been developing and testing is the Open Decision Framework, a collection of best practices for applying open source principles to business projects and decisions.
"Today, we're publishing community version 1.0 of the Open Decision Framework under a Creative Commons CC-BY-SA 4.0 license. All the files are available on GitHub."
According to that GitHub site, the Open Decision Framework is "a flexible, open approach to making business decisions and leading projects for decisions and projects that are likely to: impact our culture; or affect associates beyond your immediate team."
Red Hat said the collection of proven best practices provide the following benefits:
-
Drive better alignment between business decisions and our company strategy, goals, culture, values and mission.
- Demonstrate 'what good looks like' in decision-making and communication.
- Offer consistent guidance for teams and leaders on Red Hat cultural expectations, balancing transparency and confidentiality.
- Improve associate engagement, signal-to-noise ratio on memo-list.
Red Hat says an "open decision" is one that's: transparent, explaining who's making the decision, the problem being solved, requirements and constraints and the processes that will be followed: inclusive, in that others are engaged for feedback and collaboration; and customer-centric, which involves thinking of people "as customers with competing needs and priorities. When a decision will help some customers, but disappoint others, manage relationships and expectations while getting stuff done."
Open decisions, the company says, are made using open source principles such as the open exchange of source code and ideas, participation, early and often releases, meritocracy and community. The framework goes into detail about the multi-phased decision process, starting with ideation, moving to planning and research, then designing, developing and testing and finally, launch.
It also lists the following resources for further guidance:
"Take a look, and let us know what you think in the comments below," Fernandez said. "Feel free to remix it, and share it with project managers, team leaders and decision-makers in your organization!"
Open Source at Docker: The Blog Series
This is a three-part blog about how Docker deals with challenges in managing the open source Docker Engine project. Part 1, published last week, started "with the most important aspect of all: people." Part 2, published just today, examines the processes.
"The Docker open source project is among the most successful in recent history by every possible metric: number of contributors, GitHub stars, commit frequency, etc.," said Docker's Arnaud Porterie in introducing the series. "Managing an open source project at that scale and preserving a healthy community doesn't come without challenges." The blog series explains those challenges and how they were managed.
[Click on image for larger view.]
How the Docker Engine Is Made (source: Docker)
In the inaugural post dealing with people, Porterie explained how vital components of the open source Docker project championed by Docker Inc. -- such as IPv6 support, user namespaces and the docker update command -- were contributed by community members.
"It won't come as a surprise to anyone that a fast-growing open source project with that much attention from the industry naturally attracts commercial interests, and that the Docker project is backed by the Docker Inc. company," Porterie said. "In that context, culture and respect are essential to preserve a healthy community and a welcoming environment for professionals and hobbyists alike.
"And the numbers are here to tell! In the past year, 58 percent of pull requests submitted to the Docker Engine were authored by people who are neither maintainers nor Docker employees, 12 percent by maintainers working for other companies, and 30 percent by Docker employees themselves." In total, he said, 1,962 people have so far contributed to the project.
In Part 2, Porterie covers the processes used for working with those aforementioned people -- such as project contributors and maintainers -- which are tailored for a great contributor experience.
"The numbers we have shown in this series' previous blog post demonstrates the scale at which we are operating, and the huge amount of contributions that Docker receives from people who are neither maintainers nor employees," Porterie said. "I believe that a reason for that is that our processes are tailored for a great contributor experience first, and to optimize maintainer time (a very scarce resource!) second."
Porterie explained that contributors and maintainers work together with quite different perspectives, as contributors expend much effort in conducting a pull request and want timely feedback on their efforts, while maintainers struggle to handle the huge amount of contributions.
Visibility of the contributions -- understanding how far they are in the process, the next step and the responsible party -- are key, he said, and Docker uses GitHub labels to help with that.
[Click on image for larger view.]
GitHub Labels Provide Project Visibility (source: Docker)
"In particular, we model the pull request reviewing workflow as an iterative process where every step is associated with a numbered label," Porterie said. "The order of these steps is meant to avoid frustration for the contributor: for example, we don't want to have someone fix typos in the documentation unless we are reasonably confident the changeset will get merged (code and design approved)."
Porterie also detailed the process of contributors becoming maintainers, a process that has its own documentation repository, managed just like code.
"We want to make it possible for anyone to become a maintainer, regardless of experience and amount of time one can dedicate to the project," Porterie said. "Hence, what we're looking at is regularity: it's about being an active member of the community for an extensive period of time (over 3 months). The maintainers will notice that, and eventually they will start a vote on the mailing list to grant commit rights."
Helping out like a maintainer is the best way to become one, he said, tackling chores such as code reviews, coaching pull requests, answering questions and helping to reproduce issues and bugs.
"Finally, a fun fact is that even Docker employees must earn their maintainer rights," Porterie said. "How so? Well, by becoming an active member of the community for an extensive period of time and get voted by the other maintainers!"
The final post in the three-part blog series, Porterie said, will cover maintainer activity, pull requests and issues, which can all be measured, and some of which can be automated.