Xjyuk

I think you are being generous and, given what you say, should be able to step away from the project with a clear conscience.

If he needs the software he should be willing to find a way to pay for support, maybe not you, I think, but some support person.

I would see him if possible or send an email giving much of the information you've given here. The fact that you are doing very different things now and that support is disruptive to your main goals should be definitive.

But I agree that it is good to find a way to keep a good relationship with him if you can also achieve your main goal.

I have mixed feelings about this question, and I wanted to write an answer simply because it would be too long for a comment.

While I agree with the general sentiment that if this was asked on workplace stackexchange the typical advice would be that you do not owe him such service, I also understand that academia is a very different context, where programming is often a side-effect of the research rather than the 'main product' as it were.

The problem with this, as you're coming to realise, is that there is a lot of 'bad code' in academia. And one needs to clarify what 'bad code' means here: it does not mean that it does not do well what it was designed to do. It means that it is devoid of any of the software engineering good practices that typically make code flexible, maintainable, supported by tests covering specification and edge-cases, versioning, documentation, etc. In other words, what you call "production-ready".

There are good and bad reasons for such "bad code" in academia, but at the end of the day, the fact is that the code is bad by design. You decided it was meant to be prototype code rather than production-ready, and accepted that risk given your use-context and intent at the time. In that, your code was designed to not be maintainable, supported by tests, documentation, etc, because you had a very particular problem in mind to solve which you felt did not require or justify these features for the allocated time. I have mixed feelings about this because, as you're coming to realise, typically this is technical-debt that tends to catch up with you exponentially, but, it is what it is, what's done is done, and that's what you need to deal with now.

Therefore the crucial difference here, is that when your supervisor talks about 'bugfixes', these are not actually bugfixes as such. They are "features". He is in fact asking you to add functionality and extra work that was not part of the original intent and "design". He is effectively asking you to do new work (and boring one at that), that you have neither interest in, nor pays market rates (even if you cared to do it). The fact that this work is tangentially related to something you've worked on the past has no bearing on anything.

Your supervisor, especially if he's not programming-savvy, may not understand this crucial difference (or in the words of Upton Sinclair, it may be impossible to make him understand it, if his work depends on him not understanding it). But, however you decide to tackle this issue, part of your reply to him must make this point clear: that what he's asking you to do is, to use a car analogy, a lot less like performing trivial standard maintenance* (e.g. doing an oil change), and a lot like him expecting your machine to act like a proper general-purpose car, when it was only supposed to serve a single route, for a single individual, on a particular day. You need to impress on him that if your supervisor wants to make 12 trips in this 'car', it's not a case that if a route has problems you'll make some small adjustment for him, you're literally gonna have to design 12 routes for him, each one from scratch, because that 'car' was never supposed to be able to go on a general route to begin with, nor is it the right kind of machine for that task.

And if what he wants is a general purpose, production-ready car, really the only viable, long-term solution is for him to get (i.e. pay) someone (i.e. a professional) to build it for him.

_{* and even if it were, it would still be inappropriate for him to be asking you to commit to such maintenance for life anyway, however trivial.}

He has had your work for free 3 times already.

If he was serious he would have offered some reward the first time...

Unless you get him to commit to paying upfront, then he won't pay. He should have continued the project with other students since you left but did not, I suggest he won't be able to fund you for your continued work or other students as he cannot get any more funding for that project.

Get out and stay out is my 2 pence worth...

The typical answer over on Workplace.SE would be to say "I'll do it if you pay me X" or "I can only do it if you pay me X". You pick X high enough that you don't think they'll accept (shouldn't be too hard in academia) and high enough that you'd actually be happy to do the work in case they actually do accept it. Unless you actively want to do the work, the amount should at a minimum match what you'd get by spending the same time on your actual job.

It's possible that this will make the professor angry and impair your relationship. However, based on what you write, why do you need to keep him happy? You're in industry now, and what you describe sounds like a very one-sided relationship - you do work, and at best you'd be offered to be paid a small amount. (Or so I assume - academic salaries are typically a bit lower.)

Check your employment contract. Often, if you're working in IT, there will be terms that state that your employer owns all software you produce while working for them - which would also include all new features you produce for this previous software, even if you're working on it in your spare time. If you have such a term in your contract, you can simply tell your previous professor that unless he is willing to allow your employer to take ownership of the software and pay them a licensing fee, you will be unable to continue working on the software.

Generally speaking, I agree with Tasos's answer. But I'd like to emphasize the long-term aspects of your response. Are you still in academia? If you are, or even if you are not, it'd be beneficial for you to make sure that you maintain a good relationship with your former advisor. And to ensure the long-term life of something which you yourself describe as 'a huge success'. Rather than keep it as a vanishing line on your resume, ensuring that this becomes a useful tool that's recognized as such and widely used can only be good for your career in the long term.

So sit down with your advisor and have a talk with them about how this tool can become more generally useful. It's already in a github repository? Great. Is it public? Before you talk to your advisor, and before you do any actual further work, how about making it more ready for prime time?

Can you take some time and improve the github presentation? First, make a list of what would need to happen to make it more viable, maybe making them formal issues. Can you explain better how it works up front, throw in some comments about assumptions, reasons to do things one way or another? Can you throw in at least an example of what format(s) you expect the inputs to look like?

Then try to negotiate not doing any actual fix yourself, but helping someone else do them, filling in the doc as needed. If you need access to the university's production environment to simplify the task, I'm sure your advisor can arrange that with the IT department. And you have a whole university to work with, a listing in the job center should scare up at least a student to take up the project. If you can find an actual staff member to help, you'd be better off, as your training would be more useful in the long term. But even a student would do, as it'd force you to be more explicit in comments/documentation.

In any case, finding a successor should be your advisor's problem, not yours. You should limit yourself to vetting and training the successor, and that is already being a very good software owner.

It is my subjective opinion. If I were you I would be glad that someone is interested in and actually using my work. I don't know about other people but I find such events rare in my life. Everyone is just interested in themselves.

If your current company does any kind of development that is sold to clients, I would see if your company could provide him such service.

You mention that you are now in different industry, but even though it would be a peculiar decision to hire a company that made microcontrollers for waste collection systems that have nothing to do with data-mining software:

• The supervisor would probably be happy to choose that company, as long as you were there


• Your company would be happy to sell a product to a new client, as long as he pays adequately for that.

if that worked out, and you were assigned to this, you would have to be freed from (some of) your current time-consuming projects, and you would be working there on work hours (your leisure time is your own!). So, it could be a solution that pleased everybody, if your reasons are just the circumstantial ones those stated above, and not a dislike with the program itself.

You would probably need to spend time refreshing things, and maybe even to rewrite many things from scratch. As long as the client (University) is ok with paying the needed hours at the wage agreed with your company, that's good for your company.

Note that while you seem to consider yourself unfit, you probably still are the most suited person to do it. Refreshing that prior knowledge is likely easier than learning and understanding everything for someone else.

There are many reasons it is unlikely that would actually work out (even if your company does services for other companies): the wages the University may be willing to pay are probably quite lower than the fees of your company, your supervisor may not have the needed funds for such a project, your managers may not with to enter into an unexplored business marked, your current projects may be much more profitable than anything the University could pay, etc.

However, if your supervisor can't reach an agreement with your company, it should no longer bother you, as you did present a solution but they didn't take it.

(maybe he would claim it wasn't affordable by them, but if someone wants a service that he cannot pay for, he is not entitled to have someone do it cheaper/for free, is he?).