Take a look at slide 6 of the talk I gave yesterday at the "Opportunity of Open Source" event in Ghent: http://www.slideshare.net/blowagie/how-can-large-open-source-projects-be-monetized-66599367
When I reach slide 5, I tell the audience:
You're a developer. You have created software in your spare time, and you want to offer this software for free. You have invested time (and time equals money), but you don't really care about "losing" that money. However, if you're successful, there will be implications...
If your software isn't successful, there are no implications: nobody is using your software, hence you don't have any further investments.
If your software is successful, you will have to maintain it if you want to keep it alive. Maintaining software involves:
- Writing (and updating!) documentation,
- Fixing bugs,
- Writing (and updating) unit, integration, and regression tests,
- Educate users on Warranties, IP, and the implications of the open source license you chose,
- Update the software if a specs gets updated. For instance: I wrote a PDF library; if the PDF spec is updated, users expect me to update the software so that the new spec is supported,
- Answer a wide variety of questions.
This is a list of things I had to do once my open source project became successful. It was so much work that the core development suffered from it. Especially the legal aspects took a lot of time and money.
Today, we have a company, and we have different employees who take care of maintenance.
- a QA engineer: he makes sure the developers writes tests. He is responsible for "maintaining" the code repositories on GitHub and GitLab, for keeping Jenkins (continuous integration) up and running, SonarQube, etc...
- Support engineers: they answer questions on the closed ticketing system (JIRA) and occasionally on Stack Overflow (if time permits),
- R&D engineers: they go to ISO committee meetings where the new PDF specifications are developed. They submit new features to the PDF specification and report back to the development team about new features in the spec that need to be implemented,
- Copywriters: I am the main source of documentation, but we hire other people to port the examples and tutorials I write from Java to .Net. We also hired people to port the iText 5 examples to iText 7 (the latest iText release is very different from the previous releases).
As you can see, the job of "maintainer" isn't a job of a single person once your project gets larger. You need different people with different qualities.