Bert JW Regeer: I broke what? Taking over maintenance on existing (well loved) projects.

Existing code needs love too! Look at the truth behind open source apps on commitstrip. You can help open source projects by becoming a maintainer. I became maintainer of WebOb.

What I was told: don't mess it up. There was no existing maintainer at the time. It was handed over to the Pylons project for maintenance, but no single person was responsible for it. They all stepped back.

Side-track: imposter syndrome. See Denys Mishunov's talk yesterday. Usually you get extra responsibility gradually: for example first commit rights, then release rights. You may think you are not good enough for extra responsibility, but probably you are.

You have all these nice ideas and good intentions. You push out some alphas and betas, all seems okay. You make a full release. Then a bug report comes in because you removed something that you did not expect anyone to use.

Code grows over time. All kinds of code is there because it fixed an actual problem for an actual user. So you are faced with backwards compatibility. How much of it do you do? It depends on whether you are using a library or a tool. Libraries need to maintain more backwards compatibility. For a command line tool, the only API is the tool, not its internals.

Can you afford to lose your users? Someone can fork your code and maybe rename it and create an alternative tool.

Testing: if you have 100 percent test coverage, and you change something and a test breaks, then you can more easily see what is wrong. Does the test simply need to be rewritten for the new situation? Or is the test breakage a hint that something will break for a user, letting an old bug resurface?

You sometimes have to make a breaking change. Give a deprecation warning then.

Joel Spolsky: 'Single worst strategic mistake: rewrite the code from scratch.' This was about NetScape 6, and allowed Internet Explorer to catch up and take over. It is an option, but probably not the best.

So. You took over. You are now the gate keeper. You are a temporary guardian. Eventually someone else is going to take over. You should start looking at mentoring opportunities. Find ways to engage others, engage the community. Create pull requests instead of pushing to master.

Reach out to other communities, consumers of your code. Can you help them?

People may ask or tell you to just accept this pull request. Just push out a new version. Just is a bad word. Push back and insist on them following the standards of your project. If you require 100 percent test coverage, don't review the pull request.

I have received bad bug reports, so now I myself write better bug reports. I push myself to do better. Maybe even try to provide a fix for a bug upstream.

Be friendly when someone does crazy or seemingly stupid things in a pull request. A good question to get clarity is: 'What are you trying to accomplish?'

Twitter: @bertjwregeer.