9

I have heavily used open source software for several years, but now that I'm finally ready to dive in as a developer, I found myself not even knowing this very basic thing: what do maintainers do?

As their name suggests, maintainers probably maintain software by fixing problems, bugs, etc. They are also often project or sub-project leaders, and do the official release builds, etc. However it seems some maintainers also add new features besides just "maintaining" old ones.

What are the general things that open source software maintainers do? Is it just another word for project leaders?

Improve this question

3 Answers 3

Reset to default
6

It may be easier to think about this in a negative sense, i.e. what are the responsibilities of someone who contributes to a project but isn't a maintainer?

If I submit a patch to someone else's project and that patch gets merged in, I am an author of the project. However, I may never look at the project ever again.

Maintainers, then, are the people who do anything and everything beyond that. What they specifically do depends on the project, their interests, and their schedule, but generally speaking they are responsible for anything that needs to be done (even if they don't do the actual work and just ensure that someone else does it).

Improve this answer
7

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.

Improve this answer
7
  • How flexible is this? I mean, it doesn't look like Greg Kroah-Hartman has most of the responsibility to fellow updated specs although he's the maintainer of the kernel's stable branch, which really doesn't receive any feature updates anymore.
    – busukxuan
    Oct 6, 2016 at 8:41
  • In short, software maintenance = everything you do after your software is released, and preparing for those things (as in writing tests and docs)?
    – busukxuan
    Oct 6, 2016 at 8:43
  • Yes, it is everything you do to keep the project alive. As soon as the maintenance stops, the project should be considered "dead". For instance: iText 2 is dead since December 31, 2012; Windows XP is dead since April 8, 2014; and so on... It is a bad idea to continue working with software that is beyond the EOL status. The EOL status is either established offically by the vendor (see the dates I mentioned), or de facto when the project is no longer updated and no one is committed to answer questions and look into issues.
    – Bruno Lowagie
    Oct 6, 2016 at 9:11
  • 1
    In my opinion, keeping track of the evolution of the context in which your software is used, is part of the maintenance process. For instance: a decade ago, it was OK to use SHA-1 for hashing and a 1024-bit key for encryption when creating a digital signature, but now that collision flaws have been detected in SHA-1 and now that processing power has imcreased, you should use SHA-2 and at least a 2048-bit key. If you have software that creates digital signatures, and you fail to adapt your software to the changed environment, you have failed to maintain your software.
    – Bruno Lowagie
    Oct 6, 2016 at 9:47
  • 1
    Defending the application against security vulnerabilities. It becomes a full-time job.
    – Glenn Randers-Pehrson
    Oct 6, 2016 at 17:27
2

What are the general things that open source software maintainers do? Is it just another word for project leaders?

It is just another word for project leader. You have been using open source software for several years, therefore your are a seasoned software developer. What you would do is no different that what a project leader would do for an internal application or a commercial software product. With the caveat that when you are starting a project, you are starting with a clean slate.

You will therefore write code of course, first and foremost. Everything else is optional.

The best way you can think about it is what you came to appreciate in existing and successful projects you have been consuming so far:

  • create documentation for usage and development
  • publish releases, eventually with pre-built binaries and installable packages
  • create and run tests, ideally using a CI
  • provide support (via tickets, mailing list, forums, SO, IRC, etc) and diligently answering requests, replying to bugs, etc
  • fix bugs
  • publish your plans and if possible do what you said you will do
  • get the word out and make your project known with blogs posts, articles, etc
  • gently usher in contributions if and when you receive any

So you will basically do everything.

Good luck!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.