Open source developers can create an immense amount of value for any company that relies on open source software by giving it the ability to direct and influence aspects of the open source community. This allows the company to shape the tools they rely on and make them better fit company needs, a phenomenon otherwise known as "scratching their own itch."
Although an open source developer’s primary skill is writing good code, their value extends far beyond technical skills. Adopting open source practices requires participation in diverse communities that have a number of stakeholders who each have their own itches to scratch. Open source developers find themselves in a complex position that requires them to be experts not only in their technical field, but also in communication and collaboration.
This type of complex work presents two problems in relation to DevOps:
- It can often be hard to quantify or represent the value of this work.
- It requires a diverse array of tools that can be adapted to fit specific needs.
A big part of my job is figuring out how to increase the value of the non-development side of an open source developer’s work without excessively consuming precious coding time.
The tools of the trade
My own interpretation of DevOps is IT that focuses on applications rather than infrastructure. Today, there is an incredibly diverse range of IT tools that can be chosen to solve problems, and one of the most important requirements of a job in DevOps is the ability to choose the tool that best fits the requirements of the developers. Each open source project is going to have its own unique needs, but there are a standard set of tools that appear in many of them.
Communications
- Real-time communication (IRC)
- An IRC server allows your developers to handle short, quick communications with each other. It can also provide an informal location for water-cooler chatter that helps build a sense of community in a distributed environment.
- Asynchronous communications (Mailing lists and forums)
- These can be used for people to ask questions or discuss anything related to the open source work.
- Reporting and collaboration documentation (Wikis)
- Wikis excel at providing information in a form that's easy to read and manipulate. In most open source communities, this is the primary resource for learning the inner workings of an open source project.
- Collaborative editing (Etherpad, OwnCloud, code repositories)
- There will most certainly be instances of multiple people working on the same resources, so it’s important to have tools that can accommodate this need.
- Other public web presence (WordPress, Drupal)
- A public website is the best platform for delivering the most important information for an open source project. This type of outlet is ideal for sharing release information, general community developments, and high-level project developments.
Depending on your desires, each of these resources can be opened up to other groups within the company whose work relates to that of the open source developer, or even to external communities or individuals the open source developers need to work with.
Customization: the true power of open source DevOps
Rarely does a tool fit the job perfectly, which means the ability to customize applications by modifying the code and automate them through custom scripting is invaluable. This need for customization and automation is the primary reason open source has proven to be so useful in DevOps. While a DevOps engineer doesn’t always need to have advanced software engineering and systems administration knowledge, the ability to write functional scripts in languages like Python, HTML/CSS, PHP, and Bash will reduce the amount of time spent on standard functions considerably.
One of the biggest challenges of working in DevOps is knowing how to choose the correct tools for the job and adapting these tools to serve the needs of your developers. The willingness to dig into the inner workings of IT tools is an absolute must in order to be successful in this domain. DevOps is more than simply building development and production environments, and can often involve many tasks that go far beyond enabling the writing of code. Ultimately, DevOps is all about doing what it takes to help your developers excel at their jobs, and active participation in open source communities requires many considerations that step outside software engineering.
DevOps
This article is part of the Easy DevOps column coordinated by Greg Dekoenigsberg. Share your stories and advice that helps to make DevOps practical—along with the tools, processes, culture, successes and glorious/inglorious failures from your experience by contacting us at devops-stories@redhat.com.
Comments are closed.