openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean Weber <jeanwe...@gmail.com>
Subject Re: Status of existing OOo user guides
Date Mon, 05 Sep 2011 23:38:21 GMT
On Mon, Sep 5, 2011 at 23:02, Rob Weir <robweir@apache.org> wrote:
>
> Wearing my IBM hat, the larger issue, one that may not concern
> everyone here but does concern me, is the impact the license choice
> has on our ability to attract corporate-sponsored contributors to an
> effort that is not using a compatible license,  By analogy to the
> project source code,under Apache 2.0, it is very easy for IBM
> developers to contribute patches, etc., to that code.  We contribute
> and know that we improve the product as well as preserve our ability
> to bring that code, with our fixes and other's fixes as well, and
> include that in Symphony releases.  Once we start mixing copyleft
> components into the mix, even documentation components, we make it
> much more difficult for risk-averse corporations to contribute.
>
> So this is a matter of "help me help you".  If we can move to a
> permissive/compatible license for future documentation work, then I
> can seek contributions of Symphony-related documentations, quick
> starts, as well help with existing doc.  (In fact I've already started
> that discussion internally at IBM, with favorable feedback).  Having a
> compatible license helps align our interests.
>
> [...]
>
> Long term, the ideal from my perspective is for ODFAuthors to become
> part of the AOOo project, have their own ooo-doc/ooo-docs/ooo-infodev
> mailing list, agree to move to ALv2 for future contributions, and
> produce docs that because of that license choice can be used freely,
> by AOOo, by LibreOffice, Symphony, even freely translated for
> RedOffice, etc.  Such an arrangement also makes it easier for others
> to contribute as well, for the reasons I mentioned above.
>

One thing that has not been addressed specifically in any of these
discussions about documentation, but which I suspect will come up at
some point, is documentation version control in one or more of its
incarnations. Some of these involve change tracking at a level of
detail that I find too tedious to want to deal with. I know that
corporations often need to do this for some reason that I've long
forgotten (some ISO certification, I think), so I don't object to its
being done... but *I* don't want to be bothered. I hated dealing with
all that when I was being paid, and I for sure am not going to deal
with it when I'm not being paid. Just sayin'.

--Jean

Mime
View raw message