FAQ - Table of Contents

Patches
1.1	Do your patches duplicate functionality of patches by Ximian/ SOT/ AltLinux/others?
1.2	Is it possible that some of your patches are already obsolete (since OOo is always under development)
1.3	Could you please tell more about the patches.
Trust
2.1	Why should our organization take part in compensation of your expenses - we don't have enough information about your changes?
2.2	Is there anything that can make us trusting you more?
Fate of modifications
3.1	Why you don't just try to sell your custom version of OpenOffice to raise funds for compensation expenses?
3.2	What organizations do you expect to participate in compensating expenses?

No, they don't. The patches are for 644_M11 CVS tag, that is younger than OOo-1.1b1; It's very unlikely that they won't apply cleanly to OOo-1.1RC1/Release. It's obvious to everyone that OOo is a big office suite (from size of code standpoint) - it already has a lot of functionality implemented in it. When our developers were evaluating OOo, they carried a lot of tests to determine the ways to improve it. The tests shown that bigger general improvement could have been achieved mostly by bugfixing implementation of existing functionality and adding "little" features, rather than by mostly adding new "major features" (since most of "major" features already were there).

That's why a lot of our patches are just bigfixes. The fact that they are not huge is a sign that basic functionality was already in OOo code and that it was "correct" in major places.

None of our patches depends on the external libraries OOo not depends already (unlike patches by e.g. Ximian that make OO linking with some libraries used by apps for GNOME desktop).

The sample patches we've presented on our site were not intended to be of shocking size or of extreme complexity - they were mostly intended to be a sign of how critical bugs are fixed, and how much OOo code needs testing and improvement. Also we didn't select big patches in order to simplify analisys for a community.

But of course some of our patches are improvements, not plain bugfixes.

Also a lot of our patches are interdependant - they need to be applied in in particular order. That limited a set of patches which we could use as a samples to the roots of dependency trees and ones that simply don't have dependencies.

We believe that none of our patches is of undefined usefullnes or technically non-sound, integrating all them as soon as possible into OpenOffice.org codebase won't be a problem for maintainers.

First of all, we don't even expect you to contribute some funds at this moment. We just announced a situation with our patches to community, and now we are just asking for suggestions on how to organize accepting compensations for our expenses. However, it's recommended for all organizations willing to take part in compensation to make suggestions on organizational issues, and to stay tuned for announcements on our site (e.g. by subscribing to a mailing list dedicated for announcements) Most probably the following information would help most: Here is a link to google search results for Vladislav Kharchev (Stunnix CEO) private email address returning 4780+ links.
Some patches for a couple of years old GNOME libraries and GNOME ap- plications made personally by Vladislav Kharchev (Stunnix CEO) are posted here. Majority of patches were successfully integrated "as is" in corresponding applications and libraries. This is technically and legally possible approach - Sun Industry Standards Source License perfectly allows closed-source forks provided API and file formats of the fork are compatible with original OOo. However, we see this fully unethical. We really want to even more improve OpenOffice.org developed by community by integrating our modifications, and we believe that our modifications are very important for it. Obviously most of them would be organizations who distribute for profit operating environments for desktops basd on Unix-like operating systems, e.g. Linux and Unix distributors, and also office suites based on OpenOffice.org source.

We assume that for example vendors of various types of "Advanced Workstation" distributions care about their clients enough to join and compensate our expenses - the amount each vendor would have to compensate would be more than tolerable.

We also feel that governmental organizations or large corporations willing to deploy OpenOffice in countries with languages with scripts not based on latin (e.g. Cyrillic or Chinese/Japanese/Korean) should be really interested in having our fixes for import/export filters and for keyboard shortcuts and mnemonics handling made available.