Thanks Helge. You made your point and I fully concur. It is as simple as
that: Different tasks need different tools. Who wants to deny that fact?
Michael
Am 30.07.2018 um 16:13 schrieb Helge Hafting:
Den 10. juli 2018 00:19, skrev Uwe Stöhr:
[...]
* compatibility with other file formats: a major task is to
collaborate with others.
My solution to this is: use LyX when the others writes LyX or LaTeX.
Otherwise, use libreoffice. (word is not an option - I don't use the
required windows and I don't pay for sw where good free alternatives
exists.)
I don't think it is a problem to have more than one word processor.
Hence, I don't need LyX to do "everything". I use it for writing,
which it does very well. Certainly much better than the alternatives I
have seen. I can use libreoffice when someone wants comments on their
docx. (And others can use LyX, if they want to co-author with me.) The
required sw is free either way, and disk space is cheap enough these
days.
I don't see why LyX would be a no-go just because "it won't open your
old word documents." Word users already have word for that. Just make
it clear that this is the case, LyX is for writing new documents (and
working on old LyX documents, of course.) One-off conversion can
usually be done by copy+paste.
My impression is that file format converters are very hard, because
the underlying file formats are so different. Word positions stuff on
a page - LyX collects your sentences, keeps track of what it all is
(text, heading, abstract etc) and do page breaking just-in-time when
printing.
Before a converter can be written (by volunteer or a funded
programmer) we need to know what such a conversion should do:
* Create a converted document that renders the same way on the other
platform?
I don't think this is realistic. If we go for the same line/page
breaking, then the converted document will be full of positioning
commands, and certainly not something that can be edited in a
meaningful way.
* A "reasonable" conversion in that headings become headings, plain
text becomes plain text - and all supportable features survive
conversion?
The first problem with this, is that people *will* complain when
something looks different. Even if still looks good. A subsection
might get on another page, making it hard to phone up a co-author "to
fix the spelling error on page 13, at the end of the second line".
Another problem is that many word documents are created in a very bad
way. There are forced line breaks, forced page breaks and similar all
over. (A "good" word document is one that looks nice, and where you
can change the text size, the page size and the margins - and then it
still looks good without you having to change anything. Such a
document may not be hard to convert to LyX.) A document that has some
manual line breaks, usually breaks badly if you increase the font size
or make the lines a little shorter. Such a document will also be hard
to convert to LyX in a meaningful way. What to do about a manual page
break? Word users uses them to avoid getting a heading at the end of
page - as word doesn't always do that automatically. But they also
use them mistakenly, where word is capable of breaking automatically.
Upon conversion to LyX, the line breaking will be different, and also
the page breaking. LyX still support forced breaks, but should we take
them all, or none, or some?
Third problem: too many features that doesn't exist in both LyX and
word, which breaks conversions of any documents using them.
I am not opposed to converters, but even specifying one seems hard. If
you can solve that problem, then a converter might be possible to write.
[...]
I could add some more things. But this is not my point. I see that
most LyX developers only code for their pleasure not for the things
the potential customers need the most.
That might have something to do with not having any actual customers.
(paying customers, that is.) Volunteers generally do what they want,
and rarely care about 'market share'. I want enough 'market share'
that LyX keeps being developed - but we are there already.
You may want to look into Pavel's idea about funding features for
those willing to pay.
I don't want to blame anybody but I want to make clear that we all
need to improve our sights to the real world. There is a good reason
why more than 90 % of PC users use Windows.
I am not sure there are any good reasons for those 90%, other than
marketing & inertia. It is not as if windows actually have advantages.
(Use windows because you always used windows - even if the new version
is almost as different from the old as linux is).
Incidentally, this inertia also means lots of people won't switch word
processor - even if all shortcomings in LyX were fixed.
For example I also made my step out of the Windows world to
understand how it is under Linux. I found out that it does change the
view on the treatment of third-party programs but the main
deficiencies of LyX remain: missing file format conversion and
simplicity.
Up to now me only developed things some of use needed for their
private tasks. Jürgen Spitzmüller for example did an incredible work
on language and font support. That made LyX better for many users
every new release but without him LyX would not have these features.
So we need a plan what to develop to get and keep users, not what is
our pleasure to develop. If e.g. users polls that they miss the most
better support for tables (colored cells, sortable tables etc.) then
we should develop this, no matter that most of the developers don't
need colored table cells in their documents.
Market research and managed development has its place - but I think
you'll need funding and paid developers for that. If nobody volunteers
for "colored table cells" then it doesn't happen - even if it is at
the top of "what users (or prospective users) wants". Few people
volunteer for "managed development." Especially if they already are
used to be their own manager. When the only payment is the software
itself, we make the software the way we wants it.
Last but not least I realized that LyX lacks a feasible structure
that makes it possible to achieve a more convenient product. I
understood why other projects setup foundations. Such constructs
decouples the development from personal interests of the different
developers because non-developers play an important rile, they make
the project more democratic with elections of a board of persons and
the incorporation of users and they allow to lobby for goals. These
goals are to force and help with e.g. the development in third-party
programs like Pandoc to provide features LyX cannot deliver on its
own but needs it to survive in the long run.
Such a foundation makes sense if you can get funding. Then, you need
to manage carefully what money is spent on, to make the most of it.
Developers may then choose to work for money on prioritized tasks, or
volunteer work on more interesting stuff they themselves want.
Obviously, money can attract extra developers for "boring" jobs.
So what can be done? In my opinion, we should
- define the goal of LyX together with our users. Maybe the result is
to hide background stuff, maybe it is the opposite. Whatever it might
be, that should be the base for future development.
- setup a "board of development" that take care of user feedback and
who define the things the next version of LyX should have. Such a
board should only be 50% consist of developers. Translators are not
treated as developers. The idea is to see what people really need and
to organize its development so that several developers develop a
certain feature.
The idea is that playing in a big band is fun despite that e.g. you
cannot play your trombone when you like it but only in a way it fits
to the whole band.
Development already works that way, you cannot get a patch in that
don't work with the rest of LyX. So "you may play trombone, but only
as long as you play the same tune as the others". The problem you
describe, is that concert goers thinks it sounds better with some
drums, but nobody wants to play those. The band is having a fun time
anyway.
Helge Hafting
