At Mediacurrent, as with many digital and web development agencies, we build projects using a wide variety of open source software (OSS). From our text editors, to our build tools, to our programming languages, to our preferred hosting environments use of Linux, to our preferred content management system, pretty much every step of the way involves open source software. We feel strongly that organizations using OSS should also contribute back. As Community Lead, and a contributor to OSS since 2001, part of my time is spent helping clients and coworkers to learn the ropes, empowering them to help sustain the very software they depend upon.
Let's take a look at why businesses and organizations should consider supporting OSS projects, and then look at some specific ways for them to do so.
Why care about open source software?
After a slow start with the free software movement of the 1970's and 1980's, by the end of the 1990's open open source software was heralded as a revolution in the software world. Now, almost 80% of all businesses use open source software in one way or another, nearly doubling from 2010. As OSS is open for everyone to explore, it levels the playing field for many businesses, organizations and individuals, giving them the chance to improve their tools instead of being limited by a typical product sales cycle.
Many stalwarts of proprietary software have come full circle on OSS. Way back in 1998 Microsoft was confronting the fact that their proprietary software business was seeing intense competition from OSS, stating "that commercial quality can be achieved / exceeded by OSS projects.". Ten years later they were already changing their tune, attempting to woo OSS contributors by providing vast swaths of documentation in an interest to invite interoperability. Ten years later again, in 2018 they took out a giant checkbook and Microsoft bought GitHub, home to most of the world's open source software. Open source hasn't failed, it really has made a massive change to the world's software.
The lifeblood of open source software is contributions from the folks who use it, particularly those working for organizations which use the software. To paraphrase Soylent Green, everyone's favorite post apocalyptic movie about protein shakes - open source software is [made of] people.
Why organizations should contribute to OSS
There are lots of tangible and intangible benefits for organizations to contribute to OSS, let's take a look at some.
1. Improve staff's knowledge and skill
Working with open source software can expose staff to new concepts, new approaches to solving problems, new techniques for completing tasks. Plenty of studies show that people usually learn the best using repetition, practicing the thing they're trying to learn. While a given project for a client or organization will have custom code and functionality, the amount will pale in comparison to the amount available in wider OSS communities - one can't but help find new things.
2. Contribute towards the future stability of the toolsets your business depends upon
A business depends, in part, on the stability of the tools it uses. A taxi business depends upon its vehicles, a bakery depends upon its ovens and appliances, and an online store depends upon its website. A taxi driver would regularly clean out their vehicle, get the oil changed and perform other maintenance to ensure it runs in tip top shape for as long as possible, so shouldn't a site owner put time and finances into ensuring the site's software continues to run in the future?
3. Create new opportunities to innovate
By collaborating with others it is very common to run into new approaches to achieving a shared goal. Furthermore, when more time is available to a task it can allow people to take more risk to try new ideas, to experiment on improved or alternative user experiences, to research better structures for content, etc.
Furthermore, by expanding the array of people contributing ideas to a goal, the greater likelihood that completely new ideas will arise, that accidents might lead to wonderful discoveries, and who knows where inspiration might come from.
4. A chance to steer the ship
When using proprietary tools there is little chance of being able to decide what happens to it over time. Occasionally proprietary software vendors will seek input from their customers, but ultimately customers have little say in how software changes over time.
With open source software companies have a chance to contribute heavily to the direction software takes. As Dries Buytaert, original creator of Drupal, shared recently, the huge pharmaceutical company Pfizer has contributed heavily to Drupal 8's content workflow system because of the unparalleled opportunity to shape one of the world's most powerful content management systems, the tool their many (many!) internal sites were dependent upon.
5. Corporate social responsibility
It is worth noting that using open source software instead of often expensive proprietary alternatives can very often save a business vast amounts of money, and the larger the business the more that could be saved. As an example, it is not unheard of for licensing costs of a proprietary content management system to cost hundreds of thousands of US Dollars for a busy site, if not millions. Obtaining alternative software without the licensing costs can greatly help a business' financial status.
Some might say that companies which are saving such potentially large sums of money by leveraging software they've received for free have a moral obligation to help support that software. In the USA, businesses are legally considered "people" under the law, in that they can benefit from of the same freedoms that a person can; people are considered to have morals and ethics that determine their behavior, so why shouldn't a business also have a moral impetus to help others, in this case by reinvesting some of what it has saved?
It turns out that there's an existing concept for this - corporate social responsibility aka "CSR". Originally defined in the 1960's, this business process has been refined over the years and adopted by so many large organizations that today aspects of it are a near universal practice. Common examples of CSR include fair trade standards for coffee bean and tea suppliers, corporate philanthropy like Apple's donations to natural disasters, and more.
How organizations can contribute to OSS
While there are lots of obvious ways for individuals to contribute to OSS, let's take a look at how an organization as a whole can become better at contributing.
1. Pursue a contrib-first policy
When working with open source software to build a system, e.g. to customize a content management system like Drupal to build a website, there can be lots of improvements, changes and bug fixes needed to the core system to complete the project. The default approach to dealing with this is to build custom fixes and workarounds. This increases the maintenance burden on the project owners, thus increasing the maintenance costs, increasing the knowledge requirements to work on the project, and so on.
The alternative approach is to consider, from the outset of the project, what portions are truly custom, truly proprietary to the project, and what could be possibly reused. Anything that could be reused should then be designed to assume reuse, with unique customizations as an additional layer.
An example of this would be building custom object definitions for schema.org. The open group provides standard methods of describing things, to make hundreds of possible definitions for different types of things - recipes, books, sports, people, etc, so rather than every search service or social network having a different way of describing things, they can all use one standard that website builders work with. From there, many OSS projects which have added support for the standard, e.g. the Schema.org Metag module for Drupal 7 and 8, but because the full standard covers so, so many definitions, only a portion of these definitions are provided out of the box. The maintainers of these OSS projects have provided an initial set of schema definitions to start with, and then extended an invitation for others to submit patches or pull requests to add more as they're needed. Based upon this, if a business decided that it needed to add the Course object definition they could have their staff, or hire consultants or an agency, to build a small plugin to cover this new requirement and upload it for the project maintainers to combine into the next release of the official plugins. From that point on the website's owners are no longer solely responsible for the upkeep of that portion, it is extended across the entire OSS project's community.
2. Provide self-directed time
Starting the ball rolling on a community interaction, providing an initial patch or pull request, or starting some documentation is a great step towards a finished solution. Often times this initial push will be enough to get a group of folk to collaborating on the finished solution, but it's very important to come back and push the work further when time allows.
This is where Google's much-lauded "20% time" can come into play. While Google famously used the time to let their staff create entirely new products, other companies have used the concept to similarly great success. Atlassian, for example, established a policy of allowing 20% of their staff's time to self-directed tasks, and it led to lots of great ideas, blog posts, and more.
As career analyst Daniel Pink has noted, providing time on-the-clock for staff to explore new ideas, perform maintenance work they've never had time to do, to scratch their own itches, can become a tremendous motivator for staff. As staff motivation can be a problem for employers, trying out options like this can be a real boon to employee satisfaction, and retention.
That said, learn from Google's example and focus on allowing staff to maintain the self-directed time - don't force it to become a "120% time" system.
3. Provide training on writing tests
One of the biggest roadblocks to getting improvements and fixes committed to open source projects, especially to major projects like Drupal core, is a lack of test coverage. Ample test coverage helps make sure that proposed bug fixes actually fix the bug, that new functionality works as intended, and requested changes don't inadvertently break something. The overwhelming majority of software projects provide some means of adding test coverage, it's usually just a matter of finding the right point to start, and then incrementally improve.
One of the biggest issues with writing tests is the learning curve. Some test systems, like the Behat system used in many PHP communities or the Cucumber system used with many Ruby projects, provide a very English-like way of writing the tests. While these can lower the technical bar to writing tests so someone doesn't have to be a super skilled developer to work with them, there is still that initial "what am I doing" hand waving part of the learning curve that everyone goes through.
To work around the learning curves it should be possible to find either online materials or even some consultants who could provide training. Something as intricate and, honestly, confusing as test writing is something that should be done as a group exercise where people can learn together. Maybe it'd be worth doing a series of afternoon workshops once per week for a month - tools like Zoom, Google Hangouts, etc can help for folks who work remotely. At the very least, time on the clock and learning materials should be provided to help staff learn what could significantly help improve the team's work quality.
4. Provide time to work on non-coding tasks, e.g. documentation, project triage, regional event attendance / participation / organization
Not everyone writes software, and not everyone needs to. There's far more to software projects, especially open source software projects, than just the code. Likewise, there's more to a business than its website's software.
Consider getting the business' marketing department to help with outreach and targeted marketing campaigns. Consider having designers and UX specialists work to help make the software easier to use. Consider having content strategists, technical writers and trainers improve documentation and plan educational materials. Consider having project managers help others manage their team's responsibilities and identify priorities.
5. Commit to working with contractors / agencies who are active contributors to OSS
There are many contractors, development studios, and digital agencies, like Mediacurrent, which dedicate a portion of their work week to furthering the OSS tools and communities they use and are a part of. Consider making it a requirement that any agencies or consultants hired must have a history of such dedication to supporting the tools their careers depend upon.
6. Invest license savings into contributions
Businesses saving hundreds of thousands or even millions of dollars (or Euro, or ringgits, or..) could look at reinvesting a portion of those savings into supporting the software they're tying their business' future to. If a software product saves $100,000, consider spending $20,000 of additional staff time, or consulting, to help improve the software and its community. If the software saves $1m or more, consider hiring staff members to work exclusively on improving the software. In short, maybe contributing to OSS should be considered a philanthropic endeavor that money can be thrown at?
That's not all, folks!
The above should not by any means considered an exhaustive list. There are lots of other ways for an organization to give their staff time on the clock to help maintain the tools, projects and community the organization depends upon. Likewise, there are lots of other reasons why an organization should do so in the first place.
At this point, ask yourself: how could your organization help? How could you, as an individual in your organization, help?
Addendum
While OSS can be a tremendous boon to a business or organization, every effort should be made to ensure that the business needs in the software are handled inside of standard office hours. Just like it is unfair to push staff to work longer hours for often arbitrary business goals, it is equally unfair to push OSS contribution responsibilities onto staff to work on their own time. While there can obviously be times when the organization needs to limit focus on nice-to-have projects to complete certain business goals, every effort should be made to ensure the overall contribution inertia continues.