Project Management for Open Source Projects is based on direct experience working in a production support capacity on Open Source Projects. In the book the term “Open Source Project” is meant to include any freely available software project that does not adhere to a strict, formal software development process. The book will identify problems and provide suggestions for solving each specific problem. Maybe more importantly, though, it will offer suggestions for avoiding these problems from the beginning. Of course with any large software project, there will be challenges. The art of Open Source Software Development is learning how to deal with challenges effectively, so that these challenges don’t snowball into catastrophic failure. (p. xi)
Free software can be just as reliable, professional and usable as any other, but open source management is a different beast — for both developers and project managers. Based on the experiences of the veteran Linux leader, Shuttleworth gives practical advice for managing any project. Learn how to handle money and responsibilities, initiate projects and manage volunteers.
New users will never change: they will not search for existing answers, and their questions are always urgent—for them, of course. Sometimes they don’t understand that using open source software means they are responsible for how they use it. They don’t know the difference between a project and a product. That’s why they don’t know the difference between community support, free support, and paid support.
On many forums and Q&A engines, you can add guidelines and other tips and tricks to help newbies write good questions that include the basic information required. If possible, enable features like duplicates and automatic suggestions in order to clear up the queue and information provided. Of course, seasoned community members and project experts can be annoyed with beginners, but don’t forget that everyone was once a beginner, too.
How to select and plan your tools
Most of the early discussions about which open source tools are needed by a company will depend on its business, products, and services and how it serves its customers and employees. As the planning process and strategy map are developed by its open source program office, tools can be chosen to integrate the company’s goals, processes and infrastructure.
Ultimately, the only way to know which tools you will need is to understand what you want to do with open source.
Below are the basic steps for choosing the tools you’ll need for managing your open source program office:
- Get buy-in and selection preferences from developers and community members. To accomplish this, you’ll want to conduct detailed discussions with developers and community members. They can describe what tools have been or would work best for them. Take those recommendations and requests very seriously. Listen to the people who are going to get you to your goal. They have most likely been using many of these tools already, so benefit from their experiences.
- Understand necessary software dependencies and integrations for business-critical applications. This means understanding and knowing which open source software your business depends on so you can stay up to date with security issues and ensure software continuity.
- Research existing tools and decide what you can use as-is, or build out to suit your needs. Don’t start from scratch for every tool. See what is out there and being used in the open source communities you are in and get advice and feedback about those tools. Linger in online development communities to see what works and ask for recommendations and advice. Ask questions at open source conferences, talk to fellow developers in Birds-of-a-Feather sessions, and learn from others who are already doing what you want to do.
Once selected, the tools must then be implemented, which requires several additional steps:
- Create an internal infrastructure to support, manage, and use the tools. Through your newly-formed open source program office, designate someone to maintain and build the internal infrastructure that will distribute the tools through an online internal portal where they are kept and organized into tasks and features. In this tool portal you can make the tools available to all developers or restrict them to specific users through authentications and permissions based on their jobs and requirements.
- Provide training plans for employees who will use the tools. Just getting the tools isn’t enough. Now you have to be sure that your developers know how to use them and are mastering their capabilities. This is where training programs, whether online, in classrooms or in small lunchtime group settings, will be important to reap the benefits of their use. Ask your developers which learning methods work best for them and let them choose how they want to learn.
- Ensure the tools are centrally visible in your organization. Make it easy for developers to find and use them, preferably integrated into any existing developer dashboards that track development progress. Again, this is where the internal tool portal is going to help your company organize and distribute the critical tools for your operations.
Implementation is helpful to keep in mind as you are choosing your tools, as this may also affect your decision. A tool with a steep learning curve, for example, may require more training.
Leverage existing tools
After you have a good idea of what your team needs to meet your organization’s open source goals and the possible limitations of your own dependencies and infrastructure, the first step is to explore and learn about existing tools that are ready-built and available for you today. Since most are open source tools themselves, if they don’t meet your exact needs at the start, your development teams can contact the builders of the tools to see if they can collaborate and contribute to take the tools in new directions by adding features.
Ironically, many open source program offices don’t always reuse the tools developed by others, or collaborate with other companies to work on the tools they require to manage their open source programs. Often, they want to do that, but many businesses, including Facebook and Microsoft, already have existing tool suites which were in place before collaboration really became a discussion topic. Because they already have their tool sets and have made those investments, they seem to have less desire to adopt those of other companies.
That’s where companies that are just starting to build out their own open source programs have a significant advantage. Since they are now establishing their own open source program offices and diving into open source, they don’t have to be bothered with such limitations.
Instead, they can wisely take advantage of the experiences and successes of others and build their open source toolboxes using the proven tools created by companies which led the way in recent years. The Linux Foundation’s open source industry organization, the TODO Group, has been working on assembling a tool-filled “Open Source Program Office in A Box” starter package, which would give companies the ability to launch their open source efforts with a cohesive, pre-assembled kit of tools. The starter package isn’t yet ready, but the hope is that eventually it could make it easier for a company to deploy and configure the tools they need with less initial effort. Some of the members of the TODO Group working on this project include Adobe, Capital One, Comcast, Facebook, Google, eBay, IBM, Microsoft, Samsung, and Twitter.
Create a dashboard
Along with the proper tools, companies should also incorporate central dashboards which allow them to monitor and track their open source projects and development in real time. Many companies likely have such dashboards for existing development work and applications and may be able to integrate the existing dashboards with their open source work. If not, they should create or adopt new dashboards to improve the management of their open source deployments.
Most people don’t understand anything about free and open source software, communities, and related topics. Don’t expect that most people will learn on their own. The key is to offer education, education, and more education.
In your materials:
- Clarify your business, your project, your products (e.g., the difference between a project and a product), and teach open source best practices inside and outside the company (yes, “inside” includes your colleagues and managers).
- Write clear communication on your websites (corporate, project, docs, blog, etc.).
- Remove the words “free” and “gratis” from your communications and content, and replace it with “open source” everywhere it is appropriate.
Your target is to help users understand that they are downloading an open source project, not a product. This helps them develop accurate expectations about getting support and being responsible users.
A practical guide through the many important decisions open source project leaders need to make and the tools they use to make them.