[Discussion] Where is this project headed?

[davidclaeysquinones]

First of all a big shoutout to @sbs20 for making and maintaining this project in the first place. I love this project and would dread to be forced to use my scanner like I did before.

I want to clearly state that since development is done in spare time and doesn't generate any income nobody should feel entitled to make any demands. That said the last months development has been practically stagnated.

That begs the question : Where is this project headed? It could be that since past months have been very busy for the devs in their personal lives the project has been a bit on the backburner. This is of course understandable and nobody should take offense with that. Or it could be that this project isn't a priority anymore. That's also just fine. The point is knowing where we actually stand and what the status of the project is.

In case @sbs20 decides to continue the project the question would be which features/enhancements are or the roadmap. I personally have some proposals in mind :

• vendor driver support embedded in the images
• specify different resolutions for different beds in config (flatbed and document feeder)
• improved error handling (maybe adding a timeout time for the action to complete)

Whatever the response is I would like to hear back and know where we're headed.

[sbs20]

Hi David,

First, thanks for taking the time to write.

Yeah, development has been pretty slow, and you're right, a lot going on in life and work etc. And thanks also for understanding the nature of open source dev! It's actually been slow for a long time now - in part because the features are mostly good enough. I'm not saying it can't be improved - far from it - but I haven't had to fix any fires.

A rough guide to how I think about this project:

1. I will not leave it unmaintained. I spent a massive effort at the end of last year evergreening the Vue / Vuetify / Vite dependencies and also invested a lot of time in packaging. This, of course, does not address any new features, but it does mean that installation and maintenance is much easier, faster and more reliable. I will continue to do this and test with LTS versions of Debian and even non-LTS nodes.
2. As probably comes across in the tone of some of the documentation and my silence on the topic, I find the docker maintenance side rather hard work. Containers generally are rather ill-suited IMHO to integrating with hardware so issues with permissions, myriad ways of communicating (airscan / usb / ipp), and of course drivers makes this worse still. But on the other hand, docker is popular and I fully understand the desire not to sully a host with a load of dependencies. This topic more than any other seems to dominate issues (though perhaps that's a perception bias on my part).
3. Scanner drivers; mentioned above, but also affects a host install. I only have a couple of scanners. I tend to defer this part to the community to document either in issues or primary docs through PRs.
4. Actual software features: I am more motivated to do this and have had half of #477 and #510 done for ages. This is where the personal / work life has impacted me (and by implication everyone here). Equally, I have, as far as possible, tried to keep this app as focussed I can on the problem of scanning. It does some rudimentary conversions, collation and packaging but not much else because to do so would increase the surface area of the code so much. In some ways, I like to think this has been successful precisely because it is focussed and fits into the unix ethos of "do one thing". Taking it to an extreme, I'm obviously not going to re-implement photoshop for image manipulation. But somewhere there is a sweet spot of meeting most requirements most of the time. I try to navigate that sweet spot and will inevitably be incorrect!

With that in mind, taking your proposals in turn:

• Docker drivers: I don't have the ability (hardware) to test this across all possibilities. I love the idea of it going into the images if it makes everyone's life easier. If it goes in this repo then I (or someone) needs to support it. I can't because I can't test it (notwithstanding life outside this project). I am open to suggestions:
  • Community issues?
  • A separately owned repo which publishes its own image including all drivers or separate images for each?
  • Documentation (but wouldn't it be nicer if it just worked)?
• "specify different resolutions for different beds in config" - not completely sure what you mean, but open to it. Please file an issue - then it can be discussed separately and traced to any PRs.
• "improved error handling" - again, more detail would be useful, but if it can be done. Again, file a separate issue please.

I hope that helps.

[davidclaeysquinones]

With "specific resolution for different beds" I basically meant #477, so I'm quite happy to hear it's actually implemented.

About the error handling I'm not sure if I should issue an issue for that. In #477 which I created the scanner just would be stuck in a loop until I literally plugged the plug. Since it's impossible to cover all cases any config could in theory put your scanner in a loop. So it would be nice if this condition would be detected and that the task that is stuck would be aborted.

About the driver topic I agree that it might be to much to integrate it into this repository. Maybe you add a init folder, so that anyone can take your image as a base and any scripts in that folder that are needed for driver setup. I think this would limit the scope for anyone wanting to create an image with a driver. With the current setup it's probably already possible but some documentation and niceties would probably decrease the barrier to entry.

[whysthatso]

i also want to speak up in support of The Current Way™

i use scanservjs as a pipeline element in my document management, and i believe feeding an scan handler is and should always be the main focus of the project. I'd trade ten improvements on the docs against a single feature, so to speak.

Focusing on packaging and longevity/low dependency friction as you have been doing, is really the major point here, because i know i can rely on this piece as a tool.

please keep the approach as conservative as possible, it will save energy in the long run. and if someone else needs more features, one can always fork...

[davidclaeysquinones]

I also prefer new features instead of improved documentation since I already have everything set up. However in order to assure the future of the project I think that's essential to have a wide enough user base.

One of the key points holding this project back is the barrier of entry. Not that the documentation is bad, it just is a bit overwhelming for new users. I understand that it's impossible to have it accessible for all users, however lowering barrier to entry is essential for the future of this project.

The issues I mentioned above might not be blocking for everyone, but they for example would hold me back from deploying it for my parents or any run of the mill user.

One other issue for deployment in some scenarios is the lack of user separation. You don't necessarily want all users seeing each other's documents. Regarding this I'm against developing authentication in this project since it feels it's stepping outside of the project's scope. But maybe there could be an integration with existing authentication providers and providing the option for user scoped documents.

So this comment is a bit of a rant about why I think improved documentation and lower barrier to entry is essential for the future of this project. And also some discussion about some issues in my opinion.