Technically as a contractor, yes - but I'm not like 'most' contractors where I go in and out for a few months at a time. Rather, I'm part of the research grant and as such work alongside the scientists to make their prototypes into something more robust (sometimes market ready, sometimes not yet, depends), usually in years-long projects.

No I don't usually write docs - I get the authors or maintainers of the models I work on to do that. I do guide them, provide templates and examples, and ask for clarification when they're missing parts. I have standardized methodologies ready for that, which I developed myself mostly (this is one of my USP's, as long as I manage to convince people of the value, which is quite hard and which I often fail at). I don't think it's good practice or very efficient for programmers to reverse-engineer the whole thing because you have to become a domain expert to do so. I also think that this is why it's not for everybody - too many people let themselves get sucked in too deep, making it very time intensive. I understand the temptation, it's much more intellectually satisfying to go deep yourself. But I think you need to be as much project manager as programmer, so that you can get the actual domain experts to figure out the complicated (domain knowledge) parts, and limit yourself to factor out/replace the plumbing and introduce good software engineering practices. Those usually don't last after you (I) leave though, so it's also important not to get too worked up about that.

I started out at a research group that found itself accidentally too heavy on software people, the group got into projects doing software stuff because of that, developed a reputation for being 'the software guys' and failed as a research group because of that (it's a lot more complicated than that, this is the Cliff's Notes obviously). Through many coincidences that can't be replicated on purpose, I'm now hyper-specialized in doing the thing the OP describes in a tiny, narrow field.

The 'trick' (well it's not a trick really) to get work is to be very well connected and work hard to remain that way (being well connected is not something you find yourself in, it's the result of many years of thankless, feedback-less grinding), make your work visible to the outside (i.e. marketing, although obviously the 'buy Adwords' type of marketing is 100% useless here) and to know the science funding processes very, very well to understand incentives of all parties involved. This last part is vastly underestimated; not just for what I do, but also for researchers themselves. For example, the reason I'm usually in is when the project asks for something with demonstrable real-world application (this is a very common requirement the last decades, even for highly theoretical fields). So knowing how to put a veneer on theoretical work is a very non-obvious but highly valuable skill. ('veneer' is not 'hiding things' or 'faking', which will work maybe once or twice - I'm talking about (essentially) science communication more than 'writing papers' science).

Furthermore, being realistic is also important. I'm never going to be rich doing this, nor will I ever employ large amounts of people (or any people at all apart from the occasional 1 or 2 day freelance subcontractor). It's also something for the long haul - 10 years to become established. Other downsides are the sometimes infuriating academic politics, the eternal 'I'm a mathematician/physics/CS PhD so I'm God's gift to mankind and everything that cannot be distilled down to a theorem is 100% useless' characters you run into (they're not that common tbh but they still annoy me endlessly), and not having clear goals or even goals at all. It's like being a PhD student except worse, and with no end in sight or even a thesis to work towards. The upsides are long-term contracts, lots of freedom, intellectually more stimulating work than writing marketing websites or CRUD apps, and being respected as an expert at something even if it's a tiny sliver you're considered to be an expert at.

Looks OK, but the work of the type of person to ask for feedback on code and has put it on Github without external motivation is generally not the sort of project that's most problematic. Without unit tests and this many options who (from the looks of it) can interact with each other, I'd worry about how confident you are yourself that the right results come out though. You've probably eyeballed the results of all sample images in the repo once or twice, but do you do so consistently every time you make a change somewhere? This is only a concern when this is a long-running product, of course. It's the most common problem I find too - someone starts out with part A, works on smallish (but not bare bones) dataset (so easier to verify manually than a full out dataset, but not trivial either). Then works on parts B, C and D, verifying those each time independently or on the most common use case or whatever boundary conditions it happens to be that your dataset hits. Then when fixing something unrelated, small errors are introduce somewhere in A or B or C but you have no way to tell because it's not feasible to manually verify everything every time.

That and running only on real-world, way too big datasets. Turnaround time for running them is too long, only major problems show up, the effects of options x and y are only small so errors in them are largely unnoticeable unless you look for them - which you can't/don't on large datasets.

As to nr2, depends on what your goal is. Do you want to make this into a more polished product someone who doesn't know how to code can use, do you want to open it up so that others can try variations of your algorithms, do you want to make it into a tool that becomes standard in your field and will act as a citation-generator or at least -attractor? Something else still? Defining your goal with the software to set a framework to make future decisions in is actually the most value-added thing of all, I'd say.

For 1 and 3 you need a self-contained download, i.e. no 'download this and this compiler' etc. - just a zip with an exe. I haven't tried the tool, I can't tell if there's any functionality missing to do this (like a 'first use' tutorial, or even just some training slides/pdf and -exercises). Furthermore for 3 you need to have a command line version. It depends a bit though on how ubiquitous Matlab is in your field. Probably ubiquitous enough that it won't be a deal breaker for anyone sufficiently motivated, but some people have a natural dislike for it from their undergrad days, or others just are philosophically opposed to using for-pay tools (even if they don't have to pay for it themselves). I'm not, just saying that you might get more citations if it adheres more to a certain 'ideological purity benchmark'; you have to decide for yourself what that is in your field. This is not generally something most people are concerned with, but the type of person who would put their own stuff on Github is likely to be more sensitive to this. Again, it's a social thing - just bringing it up.

For 2, I'd start with writing some documentation (not too much, just a few paragraphs) that explains the structure of your program, and where someone who'd want to add a new method should start; or better yet, explain the plugin framework you've build if you have one.

Also for 2, you need some unit tests if any new functionality can't be implemented completely separate like through a plugin dll. Not so much for your potential contributors, but more for yourself so that you know everything keeps working when you get someone else's contributions that touch a lot of code.

In general, you're more likely to be taken seriously as a thought leader in your field if you have other users and/or some social validation that others are using it, like when you're taught workshops at conferences or elsewhere. So some introductory material, exercises that teach you all aspects of using it, maybe a link to a video or mention of you giving a workshop somewhere. In the life cycle of your software (from what I can tell), that sort of effort will yield much higher ROI than most coding will (especially the 'refactor to detangle spaghetti' coding which is only needed when you actually have a reason for it, not just for the sake of it).

All of this of course assuming you're still in academia and/or want to continue there.

I don't really have a job title, it depends on the context how I introduce myself. I'm self-employed, working alongside researchers at mostly universities and sometimes government orgs, but usually not on site - only for short stints where I need to flesh something out with partners for which it's useful to sit near each other.

I mostly write software, re-implementing simulation models to be more robust, or faster, or working with other software, or some variation on that. Part of that is also data-wrangling, presenting my/our work, and teaching others how to do software engineering rather than programming. That last is more an ambition than something that is actually (usually) successful, and I do it mostly because I like it and because the occasional person you can get to see the light is so rewarding.