I am the maintainer of a project which has a large non-technical userbase. I've been maintaining it for about four years now and adding new features as they've been requested.

I'd like to move on to other projects and stop developing for this application. Because of the non-technical nature of the users, there have been very few code contributions in the past. I don't believe I will be able to find anyone else to take over the project in my stead.

Bugs, issues, feature requests—these are still coming in. I am still responding to e-mails for help, as I am not sure if I should ignore them, tell them that I'm not working on the application, or if I should respond to e-mails in only certain cases.

What is the best way to 'abandon' this project, but still let people use the application?

Make some money

I'm guessing this is not a project you have undertaken for an employer, or for income, but something you do unpaid in your spare time.

If you are making no money on this project, then there is probably little incentive for you and no incentive for anyone else to come in fresh to deal with it. (Unless it's for a charity or similar volunteer organization, in which case you have a whole new set of problems and should probably ask another question.)

As an alternative to shutting down your project completely, why not look at the possibility of adding paid features. You may be surprised to find that your users are willing to pay, especially when the alternative is getting shut down. Of course, asking users to pay may cause many to abandon your app, but that's hardly a terrible problem when you're actively considering shutting down the project in the first place.

Another option could be to use the project as a sandbox to teach yourself new technologies. Is it a website? Upgrade to something people are talking about. Convert from Asp.Net to MVC4 for example, build a mobile version, make it service based and create an iOS app front-end for it.

Go out gracefully

You have a couple of options as other have noted. My option is to put out an end of life notice. Indicate that the product will be shutting down on such and such a date.

Additionally indicate that since this product is nearing end of life, only critical bugs that impact the ability of the application to function as designed or intended will be addressed, i.e. if the server is down you will get it up and running again.

If users have data, you may have to add a way for them to export it.

Take a look at what Google recently did with Reader for guidance. They shut it down and it was a very popular service, but it didn't fit their long term goals so the tough decision to shut it down needed to be made.

Vorac comments: A similar, excellent project that was discontinued: picoos.sourceforge.net

Heir to the throne

Announce your abandoning of the product to your community of users. Maybe you will find a successor for your role as maintainer. Try to organize some type of handover, as you would with a project in your day job.

37 Reader Comments

Open source it, or at least find someone who can maintain it. Then politely hand in your resignation. Do it right and people will respect your decision. Do it wrong, and you'll regret how you handled the situation.

Simple, just falsely claim that usage has been declining (while not giving any numbers of course, you're lying anyway), and as part of a strategy to focus on a tighter range of products (including your shitty social network that nobody wants) you will need to retire the product as part of a "<insert current season here> cleaning operation".

Ignore all petitions and don't give any further PR feedback, ruining all the user goodwill you've gathered over the years.

Then on the date of shutdown, replace the product with a page that says "we understand you may not agree with this decision" as a subtle way to tell your users to fuck off and that you don't care about them. Here you go! Mission complete.

This is a damn good question. I'm making an assumption from the observation that there were few code contributions that the project is already open-source to a degree that would allow others to contribute code. If not. First step would be to to free the code and open source.

With that, the best approach is to set up a home for the software on a well-established (free) project hosting site like SourceForge. Ensure that any final stable release binaries and all source code are accessible so the functionality is not lost for new non-technical users and so it is possible for someone with a specific problem to fix it themselves if necessary.

On the project summary pages (or equivalent) explain the "abandoned" nature of the project and identify any known outstanding issues that impact operation and the conditions under which they manifest. Make it clear that continued use of the software is totally welcome, but also totally unsupported and at the risk or the user.

Also on the summary page, make an open call for interested parties to share in management of the project and to coordinate updates to the source repositories. Most places provide a mechanism to request being added as a developer to a project. Monitor requests to join and use being added as a project developer as the point of official project hand off. If there is a decent user base, the odds are pretty good a someone or two will emerge eventually.

For style points do the basics to shell-out a Wiki for the project with some general stuff (like a page for known bugs.) and make it open for edits.

Different project host sites offer different features ... but most have some sort of analogue to the stuff described here with carrying degrees of slickness and utility.

Also. The idea of the developer trying to keep interest in the project by using it as a "sandbox" to play with new technologies is a terrible idea.

If help-desk issues, feature requests, and bug reports are already overwhelming - and being handled by one person who'd really rather just be programming, thanks - turning the project into a kludge of random technologies is NOT going to help matters one bit.

From the "very few code contributions" part of the original question, it sounds like it is already open-sourced.

An even better indication of it being an open-source project can be found by following the link in the article to the original question at Stack Exchange - one of the tags that the OP there assigned to the question was 'open-source'.

This is problem common to all software. What happens when there is not enough profit for the developer to keep working on it. Open Source means that in theory someone that finds enough value in the program can keep it alive but frankly Open Source users can often be soul sucking leeches that have a mind numbing sense of entitlement. People that do not program do not seem to think it is work.

This is a little too much defined by specifics. The question is marked "open source" why not just provide a link so people know if it's a web app or something else so context is available to help make a recommendation?

It shouldn't be difficult to find a new maintainer. If you can find the right place to announce your desire to hand over a mature product with an existing user base, there is going to be someone out there who would appreciate the experience and/or resume padding that would come along with maintaining/expanding it. Now, obviously, you will have to vet the person and make sure the license is such that they can't simply take it, turn it into a commercial product, abandon the existing users or 'hold the project for ransom' by forcing them to upgrade in order to continue to have access. That's a valid, and not entirely terrible, strategy that you as creator could take, but not one someone who takes over should.

Why not put it up for sale? If its an active community I'm sure someone would consider trying to monitize it. Why don't you tell us what the project is, the active user base etc... And we'll check it out...maybe someone will buy it?

Simple, just falsely claim that usage has been declining (while not giving any numbers of course, you're lying anyway), and as part of a strategy to focus on a tighter range of products (including your shitty social network that nobody wants) you will need to retire the product as part of a "<insert current season here> cleaning operation".

Ignore all petitions and don't give any further PR feedback, ruining all the user goodwill you've gathered over the years.

Then on the date of shutdown, replace the product with a page that says "we understand you may not agree with this decision" as a subtle way to tell your users to fuck off and that you don't care about them. Here you go! Mission complete.

Why not put it up for sale? If its an active community I'm sure someone would consider trying to monitize it. Why don't you tell us what the project is, the active user base etc... And we'll check it out...maybe someone will buy it?

Is there a good site for that? Flippa is good for websites/projects, but I'm not aware of anything good for desktop or mobile.

What are the good source hosting sites? I'm out of the loop for now, but last time I checked it seemed like SF wasn't the best option anymore.

Github seems to be the darling baby these past couple of years.

I'm not really sure why github is better than Sourceforge. My project is hosted on Sourceforge and I actively check other hosting platforms from time to time and last I checked there were the same, although github was kind of weak for binaries. I'm also using Ubuntu's Launchpad for the translation service. I didn't find any other project hosting service that has translation service and Launchpad is doing it right. They let you host your project wherever you want and synchronize the SCM with their own bazaar automatically (kind of slave mode). That was the best option short of coding your own translation page. Overall I found SF to be still the most advanced project hosting place. There are things I don't like about it but I didn't find anything better. I hate their usage of javascript for anything and the vertical layout. Why can't they let me use the full width of my screen is beyond me, but that's the same for github and also arstechnica for that matter (guys, read some shit about accessibility please!).Another alternative worth mentioning is Savannah. It's very primitive and poorly featured but I like the ad free and very clean nature of it. They are the only one who get accessibility right. They even translate their pages in several local languages.

Funny how their own page about accessibility is 160 characters wide.What you are referring to is not what I'm talking about though. I'm not talking about the line length in characters, but about the layout of the page.What I meant is that web sites like Arstechnica or Sourceforge, or Github use pixels to set the width of the content. This is wrong. The text should adapt to the size of the window. If I want to browse some text on the web next to another window in a vertical layout, I shouldn't have to scroll. When I put the windows in a horizontal layout, the text area should be wider so i don't have to scroll. The size should be set in percent, and the optimal size has always been and will always be 100%, so I can resize the window however I like and see the content however I like. I should be able to browse the web in 1600x200 or in 200x1600, depending on my needs.

Now tell me which one is cleaner.Play with the window resize and see what happens. On google code, the text resizes with the window and the layout is always 100% width. On Github, the layout is fixed to some arbitrary window size and doesn't adapt. Github doesn't feel as clean as Google code. My project is about accessibility so I care about that kind of stuff.

What you are referring to is not what I'm talking about though. I'm not talking about the line length in characters, but about the layout of the page.What I meant is that web sites like Arstechnica or Sourceforge, or Github use pixels to set the width of the content. This is wrong. The text should adapt to the size of the window. If I want to browse some text on the web next to another window in a vertical layout, I shouldn't have to scroll. When I put the windows in a horizontal layout, the text area should be wider so i don't have to scroll. The size should be set in percent, and the optimal size has always been and will always be 100%, so I can resize the window however I like and see the content however I like. I should be able to browse the web in 1600x200 or in 200x1600, depending on my needs.

That's nothing to do with accessibility, that's just your personal preference. It would even work against accessibility if the line lengths became too long above certain widths. Most people don't constantly adjust their browser width to get a good line length on each site they visit.

If you really want to use extreme widths, ars does provide a "mobile" view that stretches to 100%.

Now tell me which one is cleaner.Play with the window resize and see what happens. On google code, the text resizes with the window and the layout is always 100% width. On Github, the layout is fixed to some arbitrary window size. Github doesn't feel as clean as Google code. My project is about accessibility so I care about that kind of stuff.

Again this is your personal preference not accessibility.

Google code has a 768px minimum width and just adds white space after the text if the text extends to 64em. At the top it also adds white space between elements that are on the left side and those that are on the right side.

Github has a width of 980px and adds white space to the sides when the browser is wider.

So Google code can be slightly narrower or slightly wider than Github but doesn't stretch to 100% for the main body. For the top it just adds the white space in the middle, instead of at the sides like Github does.

em is ok. Pixel is wrong.Again, it's not about the text width, but about the layout. Google uses all the space I assign to it because the body is 100%. The main text body could grow larger, granted but it's still definitely a lot better than github. I can use larger font size and it doesn't look weird. It's definitely an issue of accessibility when the site does not display right on some window sizes/font sizes. The site becomes less accessible on some window sizes if I have to scroll. Accessibility is not about "most people", it's about being able to access the site however I want/can. Try Github on a retina display of say 4000x4000 and see the result. I know Safari can deal with it but try it on linux with Midori for instance. Google code is ok with it because it doesn't fix the width to 968px and can take different DPI. The answer "most people don't use Midori" is wrong.

Anyway people visiting Ars probably like how it looks and don't agree with me (hence the down vote) but that's my opinion on accessibility and the arguments presented hasn't changed it. I like Ars technica, I'm just saying the desktop page layout is not perfect, but there is a mobile version, which is nice.

I've walked away from projects. Hard to do at the time, but I've never looked back and regretted it. You're glad the monkey is off your back. There have been a small number of customers affected, but they've never been paying anything which doesn't make them customers IMO and asked to pay for improvements they're suddenly not interested. So just walk away. You'll have a fond memory without the baggage. Enjoy.