“Open source” carries a lot of meaning in the world of technology these days. Twenty years after the term was coined, open source projects harness the power of voluntary contributors to produce and support software that is quickly growing in its impact on every industry, in every location.
At its core, open source merely means that a product ships with the code that was written to produce it. The ability to access this source code creates the potential for modification and repackaging that is governed by a variety of open source licenses. It also can allow people to contribute modifications back into the core project, so that everyone benefits from those modifications.
As a software company built on the principles of providing superior service while also promoting the common good, we at Redis decided to bring this open source agility to a less known, but highly impactful, area — Product Documentation.
We feel that joining open source with documentation is a great combination to provide our community with:
To find out how you can contribute, check out our contribution guide.
So why did we decide to take the open source route for documentation? To understand, let’s look at the evolution of technical documentation over the last few years.
It used to be that documentation was a stumbling block in software development deadlines because all supported explanations surrounding the use of the software had to be delivered at the same time as the software itself. Worse, it started off as printed material (think user guides!) that were not only slow to create but even harder to update.
Fortunately, as technology progressed, we were able to update user documentation in digital formats, saving on the “heavy” costs of printing and shipping. Writers could provide corrections, rewrites and updates to customers just as easily as engineers could provide patches to software.
This revolution closed the delivery gap to enable companies to improve documentation during the lifetime of the product. However, there were still significant bottlenecks preventing customers from getting the best information possible.
So, what traditionally stood in the way of getting the most accurate product information out there? The WRITER!
The technical writer is the sole content contributor who stands between technical experts and customers to provide technical information that customers can use reliably and efficiently. Granted, a product without technical writers may be difficult to use, but the time and effort that it takes for a writer to understand the information well enough to write is another bottleneck.
Since technical writers are frequently the only ones with access to the source files for published documentation, any correction, rewrite or update contribution has to be entered and produced into its final format by them.
Open source gives everyone some level of access to the source files of the product. In the case of Redis docs, that means putting the source files of our documentation in a publicly accessible repository. Anyone can view those source files and edit a copy of the files to suggest contributions, changing the writer from the content owner to the content editor and curator. You can even get there straight from the “Edit on GitHub” link on each page in our docs.
This simple change in methodology opens ownership of the documentation’s accuracy to the technical experts within Redis, as well as our customers and partners who are experiencing the product’s behavior every single day. Add that to the immediate delivery of approved contributions at docs.redis.com, and we have dramatically improved our ability to provide up-to-the-moment and accurate documentation for our customers.
Of course, this is only the beginning of the improvements we are bringing to our product documentation, but we feel that this move will be the basis for a lot of good stuff to come.
So if you want to be a part of helping everyone get the most out of the fastest database in the world, don’t hesitate — Contribute!
