I’ve got a bit of a problem.
I enjoy writing software. I often write software to solve some sort of problem that I’ve had. Usually virtually any code I write winds up in my git repositories, on the theory that it might be useful to someone else. Some of the code that I think might really be useful to people gets even better treatment. OfflineIMAP, for instance, has a very comprehensive manpage, heavily commented example config file, wiki, mailing list, public bug tracker, etc. Most of these I did the majority of the work to create, but OfflineIMAP does occasionally receive code and documentation contributions from others.
Now here’s my dilemma. For my purposes, OfflineIMAP is, well, finished. It does everything I ever wanted it to do, and does it better than I ever expected it would. There are some people that would like it to do other things; for instance, optimize performance for IMAP folders with 100,000 messages in them, do UTF-8 folder name translation, and retry a sync if a connection is lost rather than crash (OfflineIMAP was designed to crash gracefully and be automated, so this has never bothered me.)
None of these are features that I care about, and I don’t have much time to devote to OfflineIMAP these days. It is not an interesting problem to me anymore as, well, I’ve solved it already.
Yet I’ll be honest and say I feel guilty about the bug reports that are stacking up in the OfflineIMAP bug tracking system. OfflineIMAP is used by people that have an expectation for improvement. My efforts to hand over maintainership of OfflineIMAP have failed (the people have gone AWOL shortly after agreeing to maintain it).
This problem is even more acute for hpodder, my command-line podcatcher. hpodder works great and is simple. But I no longer listen to podcasts. At all. (I blame my Kindle for that.) Therefore I no longer even use hpodder. Again, I feel guilty for not working on it; for instance, when language changes broke its UTF-8 support, I haven’t gone in to fix it. Neither has anybody else, for that matter.
This leads me to a dilemma. If I do nothing with my code but toss it on git.complete.org, few people will benefit from it. Most people need documentation, packages for their distribution, etc. git repos don’t tend to show up highly in search engines. So, although technically I’ve shared things with the world by putting them there, practically speaking I haven’t done people many favors.
On the other hand, if I go the whole “responsible maintainer” route, writing documentation, wiki, mailing list, Debian packages, etc., then I have the problem of, well, actual users who want actual support. I feel bad if I’m not in a position to give it to them. Many people seem to have the expectation that software is never “finished” and will continue to be improved. (Ah, if only my name were Knuth I might stand a chance to evade that one. But only a chance, given all the TeX spinoffs.) This expectation, in turn, reduces my enthusiasm for publishing my code online as Free Software. Because now I can’t just toss it up there and say “help yourselves”. Now I get angry emails about all the bug reports piling up. On the other hand, I also get occasional small contributions via my PayPal “tip jar”, which are awesome and motivating.
Despite my grumbling, I do continue to maintain OfflineIMAP, primarily as a patch reviewer these days. I take an aggressive stance on quality, and when I get patches that add features without documentation, I usually write documentation for them before committing them. If I have evidence that a patch hurts quality, I yank it (as I had to do with IDLE support, which was a great feature, but the patch caused all sorts of stability problems due to its requirement of imaplib2.py). For that reason, I suspect, forks haven’t taken off.
So what’s a person that writes niche software to do? OfflineIMAP isn’t at the level of popularity of something like Gnome, or even debhelper, and never will be; its userbase consists of people that think that IMAP support in $MUA isn’t good enough. hpodder is the somewhat small domain of console-loving podcast listeners.
What are your suggestions? Should I abolish the bug trackers and just go for simple? Is there something more I could be doing to make the community feel more empowered? Is simple posting on git.complete.org not as bad as I thought?
Hoping to nudge you in the most personal and private way to do what is in your personal interest, yet furthering projects you are committed to. Several thoughts, since you’re a past significant Debian and related SPI persona, and know the potential resources available:
– Announce the existence and orphaning of the software via appropriate debian lists. Let it go.
– Announce via appropriate screens visible to the software’s users, that they’re on their own, and will have to deal, and that there’s zero (ZERO) support or commitment.
– Cease offering services you’re not interested in accomplishing (for your health, sanity, and well being and personal longevity).
– Like Christiine Spang, search for new, willing energetic, young people desiring to learn and willing to be mentored (which implies you’re a willing mentor, to the right person that you choose.)
– Spang’s post and reference:
http://blog.spang.cc/posts/Why_ask_for_an_unskilled__44___not-yet-involved_comaintainer__63__/
– There are additional means to shed responsibility and grow projects you’re interested in. I know you can do it.
Regards
Jim Bob (pseudonym)
I don’t have a lot of concrete advice, but I so feel your pain here. I felt guilty for literally years over INN before someone else stepped up to be the active maintainer (and has since done a great job). And I struggle with this kind of thing all the time, since I can always see more work that would be useful to do than I have time to do it.
I’ve never figured out how to do this myself, but I think that at some point you do have to let it go. Say “I don’t have time to work on this any more and need someone else to pick it up” and then stop working on it. I think I’d tend towards plastering a notice to that extent all over the public resources but leaving them up, rather than shutting them down, since there’s more infrastructure there for someone else to pick up later.
There are way more things to do in life than there’s life in which to do them. One has to prioritize and focus, and sadly that means dropping things that one cares about. But I’d still release it as free software with the supporting apparatus, just with very clear disclaimers and an open advertisement for someone else to maintain it.
(The other tricky part for me is that if someone else maintains it, I have to stop caring to the degree that I normally do about code quality and let them do it their way. That’s really hard.)
Be honest. Say it does what you want and is done. That you will fix problems/bugs, but have no interest in new features. Close bug entries that are feature requests and move on. If someone wants more they will fork it.
With a little extra effort, you could post the two projects up on github, and allow the community to self-organize the maintainer graphs.
I agree with Ray. Putting the projects up on GitHub will perhaps increase their visibility, and will decrease the barrier of entry for some potentially contributors.
I am a big fan of offlineimap. so personally I suggest you to continue to actively maintain it, with utmost importance towards quality ;-)
There are a lot of people who actively use offlineIMAP and some of these people can arrange for some amount of corporate sponsorship. You can also move the sources to some other popular git repository like (git.gnome.org/github). You can also ask for a Google Summer of Code slot, and get a student to perform your tasks.
Thank you a lot for your projects. I am a big fan of your projects.
I also like OfflineIMAp very much and would agree that “it’s finished”, i.e. it does its job and can only agree with you “to continue to maintain OfflineIMAP, primarily as a patch reviewer” maintaining the quality of the software.
For the stuff, you do not use, well…game over. ;)
Sincerely,
Gour
You’ve already given away a functional piece of software. At what point did you also sign up to be the slave of random people on the Internet? You have no obligation to them unless they cough up code or money.
Perhaps this might be a sensible policy: you’ve already put in some amount of work, say, 6 months full time, to produce a finished program. Now you’re in maintenance and can expect to put in, say, 50% of that again over the lifetime of the software (note, this is maintenance to prevent bitrot, not development of the system to do different things which masquerades as maintenance). But the 3 months (50% of 6 months) is spread over the rest of your expected programming life (say, 50 years), or about 2 days a year. That’s enough to compile it and get everything functioning again, and push a new maintenance release out the door.
Leave the bug trackers, but distinguish between feature requests and error reports. Put a big call out for patches: “Like this code? See a feature you want? Give back by implementing it and sending me a patch.”
If Linus Torvalds or Simon Peyton-Jones came along and asked for a feature, you might respond differently, since you have gotten so much code from these people over time. On the other hand, they’re more likely to send you a patch.
[Replying to the first two sentences of Frederick’s post.]
That’s exactly what users of Free Software need to learn. You already offered them a gift; it’s just rude if they think you would have to do even more for them.
I hope Free Software users never internalize that; it’s an assumption that developers are all irresponsible assholes.
Putting software forward as useful and then not following through is lying, plain and simple – it’s saying that this will be useful and solve your problems, except it doesn’t; it’s Lucy pulling away the football at the last minute. ‘Stupid User Brown!’
Taking a contractual viewpoint – ‘you didn’t pay the developer so he owes you nothing!’ – is morally myopic, antisocial, & egotistic. If Goerzen is no longer maintaining his software, then he should make it clear, so his sites and materials do not cause false expectations, and be done with it, and then things will be fine. You put away your toys when you’re done.
Gwern: But in this case it *is* useful software. OfflineIMAP *does* solve problems in its current incarnation. So in this case it’s not lying.
Your assertions about being myopic, antisocial, and egotistical are all value judgments, and I don’t agree with any of them. Goerzen offered software, it serves a purpose, it has saved people time and money. He doesn’t owe anyone anything.
Note: I didn’t judge this behavior as egoistic or social. I just said that the developer *must not* be forced to do something more.
I surely agree with you that the developer *should* care about the software he released.
You owe absolutely nothing to anybody that hasn’t paid you for your services (together with your agreement to be paid for said services). You’ve generously made your code available and in a way that can be shared. If people don’t like the fact you’ve moved on? Fornicate ’em. In the ear. With a chainsaw.
My recommendation is to explicitly flag the software that you no longer have a desire to support. Encourage forks. Encourage others to take up the flag you’ve decided for whatever reason to let fall. If nobody wants to take it up? That’s their problem, not yours. Let the lazy, fatherless sons take the blame themselves.
I think there is nothing wrong with saying: „Here is my code, I’ll implement any feature I want and need, but if you expect more, be prepared to contribute.“ I do that all the time :-)
You’ve scratched your itch; let others scratch theirs. If the latter is sufficient, that’s the start of building a development community around your software.
Best thing you can do is help bootstrap that community. That means, be there to answer questions/etc when folks are on a learning curve. Run a repo, a bugsdb, support list, IRC, etc, either yourself if you have the time and inclination, or host it somewhere that caters for such things. And (if this isn’t teaching a granny to suck eggs) get to a talk on the Apache Way, and the distinction between Open Source (which may mean no more than “throw it over the wall”) and Open Development (“community over code”).
As someone who is pretty passionate about this subject. http://xenoterracide.blogspot.com/2010/03/unpaid-volunteer-work-is-job.html and thinks that as an open source dev you have a responsibility. I also understand that sometimes you want to walk away. My advice is the same as some of the others here. Put it on github, and slap large notices that you aren’t maintaining it at the top of any docs. Link to this blog post too. Say that you may accept patches but that’s not guaranteed. I’d also suggest that if a patch is interesting… reject it if they didn’t write docs for it. But the biggest thing here is make your users aware that it needs a maintainer and you’re quitting.
I read your post, but here’s the problem: if by posting my code in public I’m committing to maintain it longer than I use it, that raises the barrier to entry for posting my code in public. In other words, less of my code is going to be made public to start with.
Right now, I post the majority of the code I write on my own time in public. If there was an expectation of continued support, I’d put more in my private rather than public git repos.
This is what I would do:
– make it very clear in the documentation, in the project homepage (if there’s any), in the bug tracking system… in short everywhere, what the status of the project is (abandoned seems appropriate). So you manage users expectations
– make a very visible public offer for someone to take over maintenace/upgrades of the project, you never know someone might be interested in doing it if you stop
A few more comments on Hacker News: http://news.ycombinator.com/item?id=1278898
Thank you everyone for your thoughts and suggestions. I was already leaning in the general direction that these comments have run. Part of the question for me now is whether to continue the download site, wiki, etc. at software.complete.org or to just move as much as possible to github and discontinue the rest.
I am no big fan of redmine, and dislike having to maintain it. But it works for me at the moment, and has a wiki, bug tracker that integrates with git commit logs, etc.
I have also toyed with setting up a MoinMoin instance to replace redmine, and moving code to github.
I reviewed Github last year, and wasn’t entirely pleased with it. Bit it sounds like they’ve fixed a lot of the issues I identified at http://changelog.complete.org/archives/1123-free-software-project-hosting
Is gitorious being used much?
I’m surprised no one latched on the idea you stated yourself. Kill the bug tracker. That lkml does well _because_ they (mostly) don’t use one is a falsifiable hypothesis, worthy of testing.
I’ve been using offlineimap for some time and regardless of what you choose to do I appreciate your efforts. I don’t feel you have any obligations to users like me. Anyone who says posting code amounts to a promise of support has not been contributing enough to know how much detail work is involved. Over the years and with accruing project portfolios that adds up.
Please don’t let them discourage you from contributing what you can on your own terms. Especially if those contributions only show up in a git repository I don’t see how it could reasonably be misinterpretted. Unfortunately, there is a small portion of the user population who are vocal and clueless.
That said, I would certainly miss offlineimap if it became unmaintained and suffered from bitrot. Thanks for continuing your efforts at finding a reliable maintainer.
If you’re up for making a little extra money, and can find the time, I’d say accept some contract work to develop OfflineIMAP or other projects.
I have done that once in the past. This doesn’t seem to be an area of great interest among people that would pay for such things.
Github seems like an excellent move. Thanks for all of your work on offlineimap; it has become a key part of my email workflow.
Do you happen to know if HaskellNet is stable/complete to the point that a similar tool could (somewhat easily) be written in Haskell?
I would love to rewrite OfflineIMAP in Haskell. It would probably take half the code to do it, plus I’d be finally free of the terrible imaplib.py. Oh the joy!
Now to find the time…
Thought you said you were done with OfflineIMAP. Yet here you are, looking forward to… Oh, wait; this’s a new project. Never mind.
:) :)
As one of the people who reads your blog regularly and follows what you say on the lists: once again, you’ve precisely articulated and crafted something of wider public interest.
Hpodder first – if you don’t use it any more on a regular basis – check the popcon count. If it’s small, bundle it up for github / gitorious, put out a public announcement. Change the status in Debian – pass it to QA / announce that it’s essentially feature complete and in long term maintenance mode AND STOP..
Your time taking Jacob to see fire engines and steam trains is more important in any scheme of things :)
Offlineimap is more problematic – you feel obliged to more people, there’s indirect pressure that you’ve placed on yourself to “do the right thing”.
Tom Limoncelli’s book on Time Management for System Administrators [O’Reilly] nails the personality type exactly – caring, will drop everything to solve a problem, intense – but he puts it in a much better phrasing than I can from memory and with more fun. I commend it to you :)
You have done/do a fine job on these packages to the best of your ability but one man can’t do everything. Admitting that you can’t spend the time isn’t hardening your heart against the user community / damaging them in any way. It may just mean that you have competing priorities, hard though it is.
Does a responsible maintainer have to provide packages for every distribution? Surely if the software is actually useful, someone associated with each distribution will volunteer to package it?
And hopefully, a number of those are real maintainers for the package; not just package-monkeys. In any distribution which strives for any kind of decent quality, the package owners ought to be capable of dealing with bugs for themselves, not just punting them upstream.
It’s not hard for these people to publish a git tree and ask you to pull from it. Often I’ll give people accounts on git.infradead.org and get them to put their trees there — or even just give them direct write access to the main repository, once they’ve proved themselves. Just make it as easy as possible for any interested party to contribute. That goes for the documentation too, if it and the web site aren’t already in a git tree.
Another tactic I find useful is being straightforward in the bug report that I’m unlikely to do it myself. Sometimes I’ll give some hints as to how it should be done, to help out. Or a proof-of-concept patch which kind of works but has a lot of rough edges left as an exercise for the reader.
First of all, thanks. I am a happy offlineimap user and agree that it is basically finished. Put a not on the homepage saying that you only drive it in maintenance mode and that you would be happy to hand over maintainership.
I am not sure that moving a big chunk of code to github will invite more contributors than it does now. The code is currently one “git clone git://git.complete.org/offlineimap” away, how much easier is it supposed to be?
I don’t have much advice, but feel your pain. I can completely your position though. Thanks for not just letting it all go without trying to get someone to take it over.
The advantage of github is that one can readily see who has forked the code. It also makes it very easy for others to publish their changes. Of course, you still need someone to collect the changes, review them, and integrate them into one cohesive bundle.
I think there is a distinction between “bugs” and “feature requests”. The feature list is whatever you want it to be: if you consider it finished, it’s finished. A bug is something that goes against the feature list, and either affects your own usage or could potentially do so. I think you should continue to fix such bugs, if brought to your attention. But you should feel free to ignore feature requests, and to declare certain usages “unsupported”. (Of course, if someone does send a patch for a new feature that you like, you are entirely free to accept it…)
The problem with that approach is people that send a patch for a new feature, then don’t support it. Of course, they have as much right to leave behind their contribution as I have to leave behind mine. But if I’m fixing bugs, it requires me to fix bugs in others’ code. Either that, or spend more time than I have to review/test it.
Hi John, as a user of free software I don’t expect the founder of a project to spend her life fixing bugs and adding features to it. I understand you might feel guilty. However you decided to write software to address your needs. Then you kindly decided to share your code to help other people that may have the sames needs. Now this post clearly explains that you no longer want to fix bugs and add features.
I like you honesty and think you should clearly look for maintainers. At the beginning you may help the new maintainer by doing some mentoring and reviewing patches with her. After that the project will live its life. Sometimes you will accept that it does not take the direction you wanted because you no longer lead the project. But I guess new maintainers will always welcome some good advices from you.
As suggested by other comments, the first step should be to clearly announce that you are looking for new maintainers for some project. Coding style and hacking guides would really help to keep conceptual integrity in these project.
The developer, certainly, does not have any obligations, but the problem is that users have some expectations by default. And we have to be clear.
Probably the community needs to develop certain recognizable grades of the level of project support. Like alpha-beta-release quality, or version numbering, but to take into account how the project is supported:
* not developed anymore / frozen
* only bug fixes are accepted
* bug fixes and patches with new features are accepted
* the project has a person who fixes bugs regularly
* the project has a person who fixes bugs and adds new ad-hoc features
* the project is being actively developed, there are some future targets
Alpha-beta-… are already taken for the readiness of the release, but we can use any other left-to-right non-latin alphabet for this purpose. For example, hpodder ሀ (Hoy) or offlineIMAP መ (May)…
This can reduce some non-realistic expectations, and can also help users to choose the software.
Hi John, thanks for articulating this problem. I feel it too.
It seems to me that one useful piece of work to do while you are still project leader is to identify the tasks and roles that are associated with the project, and document them clearly, showing the responsible person for each, or “unfilled”. Draw a crisp line around the roles you want to hold right now. Treat this as your contract with the world, and with yourself – “I will do activites A, B and C, but I will stop myself from doing E and D because they’re not in my contract.”. Ideally D and E will queue up somewhere visible to encourage volunteers.
Related and also useful for the project leader to do is improving the project’s portability/transferability to other maintainers, in parts or as a whole. For example, making it possible to run the project entirely out of the public infrastructure (github, google code etc.) rather than a single private redmine setup.
In theory, you should have the moral obligation to not
claim to ‘maintain’ something when all you actually do
is drop other people’s attempts at contributing
something onto the floor silently.
Of course that is true. But that’s neither happened, nor was it the question. The question was not whether or not to deceive users; it was what to do about the situation.
You are not obligated to continue volunteering your time if the project no longer interests you. Simply announce that these projects are no longer actively maintained, and that you would welcome the opportunity for new maintainers to take them over. Once new maintainers are identified, hand over the reins.
JimBob hit the nail on the head. “Like Christiine Spang, search for new, willing energetic, young people desiring to learn and willing to be mentored (which implies you’re a willing mentor, to the right person that you choose.” There are plenty of folks right outside your door and I’d be glad to mention their names when I see you next week! You would be an awesome mentor to young geek wanna be’s!
Your sense of ownership is admirable, but your life, and what you decide to do with it, is yours to chose.
I’ve dealt with this several times. Two key points:
a) You do not have an obligation to do anything. You’ve published your code as free software, and that is a great gift to the world. Anyone saying you must (MUST!) then do further work is simply wrong, even if it is you saying that. Any such requirement leads to madness, burnout, and _less_ code being released. It is nice if you provide support, of course.
b) From a purely pragmatic point of view, it can help everyone if you make it clear what the support status is for each program. I can only echo everything Russ said about this.
An alternative option that would benefit the community is to do a merger with a similar project. OfflineIMAP does not have a strong “market”, which is why it would be a great benefit for both users and developers to do a merger if a similar project exist.
But where are the offlineimap bugs now? I just hit one, google tells me there used to be a bug at http://software.complete.org/software/issues/show/197; but the redir link doesn’t help me much. Bug trackers are not only means for getting patches in; they are repositories of knowledge as well.
I have submitted bugs and at least one serious patch in the past. It’s a shame that info has seemingly vanished.
As I took software.complete.org offline, so too went the OfflineIMAP bug tracker. For some other projects that I still have time to actively maintain, I set up an issue tracker on Github and migrated anything that looked like it was still relevant.
Doing this for OfflineIMAP was simply a monster job that I didn’t have time for.
I did use a webscraper to save off a static copy of the website before I turned it off. It’s a 25MB tar.bz2 that expands to 216MB. If you or someone else wants a copy of it, I’d be happy to get it to you. The URL you mentioned is safely in it, and you are welcome to create an OfflineIMAP fork on Github and load the bugs into it.
I did not turn on the issue tracker on Github for OfflineIMAP, partly following the advice I got from some here. Nobody was actively working on that list. Not me, and not anybody else from the community either. People expect that when they submit a bug report, that someone will be working on it, and putting a bug tracker that has no users up there seems to provide a promise that won’t be fulfilled.
OpenSource is a wonderful ethic. By contributing to it you make the world a better place. With better free software.
OpenSource will only succeed if the right people are prepared to give to it on a charitable basis. That means developers freely donating their time. My advice; choose one project that you wish to maintain or/and develop further. Decide how much time per month you are prepared to give. Look upon that time as your bit of giving back; your bit of charity. If it is only a couple of hours per month, that’s ok. It’s more than many others give. And just that couple of hours may be enough to ensure that the project never truly dies. Enough to ensure that progress does get made on bug-fixes, however slow that might be. Enough to respond to well placed questions or patches.
I don’t agree with the comments that state the giving a project to the OpenSource community is enough. I don’t agree that your responsibility ends there. That is like giving a tractor to a third world farmer but then failing to supply the petrol or maintenance. It is not a useful gift. So hand over to others those projects you are no longer interetested in. Choose the one that you accept responsibility for. Be magnificient! Give your time and keep that tractor running. You are feeding the world !!! (I mean the OpenSource world of course!)
Thanks for contributing to OpenSource.
Also in cases in which your dog is unlikely to
survive, they can be euthanized on the spot so they won’t suffer painful,
slow death due to kidney failure. So, ladies, if you carry gum in your
purse, make sure it is out of your dog’s grasp or zip it up.
The “sports cap” style tops of most water bottles provide ease of use for squirting
water into your dog’s mouth.