Challenges of maintaining a highly-used Drupal module
I have been for a time in 2011-2012 co-maintainer of Simplenews module, one of the top 60 Drupal modules at the time.
Believe it or not, maintaining such a module is often not about writing code. I suspect 50% of my time was about cleaning the issue queue... Without a clean issue queue, it's impossible to work. That's probably one of the reason Views module now has a dedicated team to do it ;-) And with such a user base, there is at least a new issue per day (that actually seems not so much, but with 150 other issues in the queue, that's still something else that will take your time).
What does "cleaning" the issue queue mean ? Well...:
- Closing duplicates (it actually starts by "finding duplicates", it's hard to know all of your issues by heart)
- Changing version of "Feature requests"
- Answering "Support resquests" (this one is tricky, the subjects are very widely distributed, and not always Simplenews-related ;-))
- At last: fixing "Bug reports" / doing "Tasks"
Each time you release a new version, a lot of people are going to adopt it rather quickly, and some of them will submit the same issue, not always willingly: but just because they don't have the same technical vision of your module than you, as long as the message is different, or simply concerns a different line of the module, they will submit another issue. Your first job is to close them (with a nice message, never forget the user at the other end of the internets is not always a developer, and may not understand technical terms as well as you).
Handling "Feature requests"
Of course, you have a vision of what your want your module to be (and if you don't, you really should !). Why is it so important ? So you can prioritize the upcoming feature request (and they will come). Maintaining a module, if it is used enough by the community, should be treated like any other client project you may have, with versions, expected delivery date, and so on. Only difference, you won't get paid to do it. That doesn't mean you should treat it any less. You have people expecting things from you. Not fixing bugs fast enough will bring your module to the abyss, and not accepting any feature request will bring a fork fast enough too. Solution: having a plan, and explaining it. People understand, as long as you're open about it.
Answering "Support requests"
Simplenews, on this point, is probably different of some modules, as it is mail-related. Therefore, we see a lot of support request about formatting a newsletter, SMTP servers, HTML mails, ... that are not directly related to Simplenews, but what can we do? So we at least try to answer them, or if possible divert them in the correct issue queue (Mimemail, SMTP / PHPMailer, or one of the many Simplenews-contrib modules).
For most developers, that's the most (the only ?) fun part. We have to dive deep into the module's code, sometimes with a setup quite more complex that what the module was designed for (thousands of newsletters with several thousands of subscribers, but what do you need that for ?!?!). When I started helping with this module, it was through some two-liners: adding a permission and using it on some hook_menu entry, things like that. Then I got more invovled... But sometimes, I was still lost about the sending process, and it took me time to fix some bugs. Sometimes the work needed was more impacting, and a new branch was needed. And actually, that was the most difficult thing for me at first: managing 5.x-1.x, 6.x-1.x, 6.x-2.x AND 7.x-1.x at the same time. I was forced to quickly let go of the first two.
This post may sound bitter, or quite frustrated. Not at all, I love being able to help people using Drupal easily by providing a module (and associated services) that just works. But after a time I didn't have any client needing Simplenews functionality anymore. And the main issue there is not only that I was not even using my own work, but I simply was not seeing on a day-to-day basis what the users are facing as lack of documentation, or cluttered UI, or simply dysfunctions.
So if I have a single advice for people wanting to maintain a module, I would quote "Rework" (by Jason Fried and David Heinemeir Hansson, from 37 signals): "Scratch your own itch". Maintain a module that you use, that you love, that you need. It'll be easier for you, and much more rewarding day after day.