[sane-devel] discussion: Future of SANE-project

[David N. Paules]

Perhaps I misunderstood SANE's goals. From what I've seen, the backends =
do not dictate what the front-ends look like, only their capability. I =
don't understand why the bluster about multiple front-ends and more =
control over the gui. I was under the impression that one sane backend =
for a device will support multiple applications (front-ends) such as =
image capture, OCR, digital camera photo image acquisition, video =
acquisition from a digital camcorder, etc.

Besides, the SANE project is open for review/suggestions for =
enhancement, so why not get some feedback from scanner makers on what =
makes SANE a non-option for the future? What 'minimum requirements' are =
missing from the current architecture?

I can see your point about GPL'd backends. I agree it is easier to debug =
and extend them. But here's my point: Do you want to be the one always =
repairing and fixing scanners to work with SANE? Or do you want all the =
manufacturers to feel responsible for ensuring SANE compliance? If SANE =
is architected intelligently (i.e., backwards compliance with older =
backends), open source backends may not be necessary.

The manufacturers will currently see the SANE org as a free resource for =
reaching other markets they didn't officially target (i.e. the *nix =
markets). There is no urgency or requirement for them to support SANE =
just because the project is open source. In fact, that is the number one =
reason they will NOT be concerned. 'Those hackers at SANE-project.org =
will make my device compliant with their software. And I don't have to =
pay for it.'

But, if the ultimate goal of SANE is to supplant TWAIN as the standard =
for accessing image devices, shouldn't more effort be put on making SANE =
the future standard. This route will cause scanner makers and their =
support network to conciously choose to either support or not support =
the new standard. The SANE project's developers should then concentrate =
on enhancing the architecture, ensure backwards compatibility, create =
and market compliance badges, create plugins for Adobe products (like =
existing TWAIN plugins), etc. and not write new backend modules for each =
new device that comes on the market.

Perhaps working examples demonstrating how scanner makers can leverage =
their investment in TWAIN support while migrating to SANE might be =
useful for getting scanner makers to take notice of SANE. If an upgrade =
path was readily shown, techno-geeks at the manufacturer might prefer =
and sell the SANE idea to managers within the company.

Formal propoganda of industry heavyweight support (a consortium of =
scanner makers and front-end application development houses) on the =
web-site might make other makers feel the need to join in.

Without this kind of direction, I simply see SANE as being a =
hobbyist-level effort which is why I questioned the future of it. Thanks =
for listening and answering my questions.

Dave Paules
Quantum Leap Innovations

> > m. allan noah wrote:
> > > it is important to remember that the developers of sane=20
> are volunteers=20
> > > just like you. most of us got involved because we had a=20
> lame scanner too.=20
> > > we probably dont have time for such evangelism.
> >=20
> > But if someone was offering....
>=20
> sure, sure. i got no problem with someone acting as a liason=20
> to hardware=20
> vendors. i do this myself with fujitsu.
>=20
> > > that said, even if someone had the time to run around and=20
> convince vendors=20
> > > of the merits of sane, there would be at least two=20
> recurring sentiments:
> > >=20
> > > 1. sane spec is not complete, cause it does not support various=20
> > > LEDs,buttons or sensors that the manufacturers believe=20
> add so much value=20
> > > (and brand distinction) to their products.
> >=20
> > Proposals to include this have been discussed, possibly=20
> input from a=20
> > manufacture would help.
>=20
> sure, and none of us ever had the time to actually formallize the=20
> proposal, let alone get input from manuf.
>=20
> > > 2. they are going to want more control over the gui so=20
> they can do things=20
> > > like show pictures and diagrams of the scanner, which=20
> means they are going=20
> > > to write their own front-end half the time.
> > >=20
> > Or repackage existing - under GPL - is this a problem.
>=20
> a plethora of front-ends is not a problem, but it does defeat=20
> some of the=20
> point for the vendor who is also making a backend.
>=20
> > > then, i as a developer, and hopefully you as an=20
> open-source/free software=20
> > > user would have another complaint:
> > >=20
> > > 3. closed-source backends are much harder to debug/extend=20
> than free, even=20
> > > if you have the vendor to complain to.
> > >=20
> > This is looking for problems, why assume they will be closed source.
>=20
> because experience shows that they will be, esp. in the=20
> cheaper hardware=20
> segments, where the vendors are likely to cross-license tech=20
> from each=20
> other (think winmodems).
>=20
> > > that said, there are a couple vendors who do make=20
> backends (brother comes=20
> > > to mind).=20
>=20
> i can say that some vendors, (fujitsu) have been quite=20
> talkative about=20
> their products, and i have specs for many of them, without=20
> signing NDA,=20
> and whatever code i write is at no cost to them or you, and=20
> under the GPL.=20
> seeing more of that would be great.
>=20
> allan
>=20
> --=20
> "so don't tell us it can't be done, putting down what you don't know.
> money isn't our god, integrity will free our souls" - Max Cavalera
>=20
>=20