> The change is really easy and no big thing.

Right, the change as such is very small and the benefits are negligible - but 
the effect is very large. The cost-benefit-relation is near catastrophic.

Who will gain?

A handful of developers who program extensions that are designed to work in 
more than one component. Listen to Bernhard Marcelly! He is a very renowned 
developer of extensions and right about the fact that most extensions are 
written for only one component.

What will be gained?

About 3 minutes of time saving.

Who will lose?

The overwhelming majority of extension developers, their users and/or 
customers, and the reputation of OpenOffice in general.

Why is this a big thing in the real world, and a bad one?

Again, listen to Bernhard Marcelly. Or listen to me. For more than 20 years I 
make a living out off a successful commercial product for schools and teachers 
at home that comes as an add-in/extension either for Microsoft Word (VBA, 
formerly WordBasic) or OpenOffice Writer (StarBasic). My tool is large, it adds 
about 65 teacher-specific functions to these word processors, it comes with a 
lot of additional components, documents, fonts, etc.. So I, too, know what I'm 
talking about. And moreover I have to deal with complex mixed system and office 
environments in schools and among their teachers.

1. Users
Schools and teachers are mostly inexperienced users. Therefore many of them 
like to stick to working systems, they are certainly not at the front of 
technological change. Backwards compatibility is an absolute must, where you 
have to deal with a user scenario like this. My product is currently compatible 
with Microsoft Word 2000 to 2010 and OpenOffice Writer 3.0 to 3.4. Your 
proposed "small" change will break backwards compatibility completely. Consider 
the following example: School "Little Primary School" buys a school license, 
use at teachers' homes is included, because the main part of lesson preparation 
is generally done at home. Some teachers are using rather old versions of 
OpenOffice at home because they don't dare to update, or there are even a lot 
of old computers at school, where nobody has the time to update. With your 
proposed change, both I and the person who is responsible at school would have 
to explain which version of my extension to install on which OpenOffice 
version. That will literally swamp half of the school's teachers, who often 
have difficulties to even tell which version of OpenOffice they're using. 
Believe me, I know my customers!

2. Extension developers
a) We extension developers are caught between all stools. Office developers 
have to write the programming environments for us but generally don't really 
know what we are doing. Knowing this, even otherwise arrogant Microsoft (Office 
for Windows department only) always took great care to ensure close connections 
to VBA developer communities and backwards compatibility for VBA. E.G. parts of 
our code are very old (1992) and written in WordBasic, but still work perfectly 

On the other hand, Microsoft's Office for Mac department never came to 
understand the importance of VBA, which resulted in Office for Mac 2008 coming 
without VBA at all. We decided to develop an alternative, an extension for 
OpenOffice, which I already had had in mind for some time then. This was really 
hard and took much longer than I thought, because the learning curve in 
OpenOffice is unbelievably steep, much more so than with VBA or scripting 
languages. (BTW, therein lies the problem you should really care about.)

What I want to say is: Please don't follow the way of the Office for Mac 
department at Microsoft, don't be arrogant about the wishes and complaints of 
extension developers. Listen to Bernhard Marcelly, listen to us!

b) Your proposed small change will give a lot of us a lot of headache. Not 
because of the change as such, but because of a lot of extra work we have to do 
for a new release, because our users being confronted with more update 
complexity, and we being confronted with growing need for support.

3. Online update mechanism for extensions
Of course this could work, in an ideal world. But how many of the old but still 
valuable extensions in the repository have it even implemented? Not many, I 

Now, I do have it implemented. But will it really work? I remember the time 
when I first published the OpenOffice extension of our commercial tool. On 
Windows systems, which are used by most of our customers, part of our package 
was a third party tool for license validity checks that made use of the Windows 
registry. 3 month later OpenOffice 3.3 broke the way, StarBasic in all former 
OpenOffice versions had given access to the Windows registry, the way that was 
officially recommended and explained in a sample StarBasic module.

How did this happen? Well, it was a fix gone wrong for some data type, 
something that had never caused a problem before but was thought of as bad 
design. Please don't fix things that don't cause any problem at all.

Let me pose another question in all earnest: Will - after applying your small 
change to OO 4.0 - a broken extension even be loaded to the point, where the 
online update mechanism is called? 
4. Maintaining extensions over time
Jürgen, you recommend to use a max version dependency in extensions.

a) I would never do that, because it makes customers angry. And one really 
doesn't want to make customers angry. When an extension doesn't work anymore, 
they'll notice and ask for support or whether they need an update. On the other 
hand, when a message box comes up telling them something along the line that 
their version of the extension is outdated because they recently updated 
OpenOffice, they'll complain about unnecessary extra complexity - and rightly 

b) You wrote: "I [...] would do a micro release if I change nothing else".
How much work does a micro release for OpenOffice mean? Would you want to do a 
micro release just because OpenOffice on Windows, MacOS, or Linux had an 
in-built max version dependency concerning the operating system? I don't think 
so. This is just a bad fantasy!

Please, try to imagine what an otherwise totally unnecessary micro release 
means for us extension developers, for our customers, for support. You seem to 
assume that extensions are rather simple things. This is wrong, in my case it 
would take a lot of work, too, albeit scaled down to a one man enterprise. I 
simply don't have the time to make micro releases just because of max version 

Jürgen, OpenOffice is on a stable pathway again, I really used to admire your 
patience, your objectivity, and your leadership in getting Apache OpenOffice to 
work. But the reputation of Apache OpenOffice is still small and fragile, at 
least in the education systems of the German speaking countries, where I know 
the sentiments very well.

E.g. after the failure of Microsoft Office for Mac 2008, my extension has won 
thousands of users for OpenOffice, in spite of the rather long period of 
uncertainty of the future for OpenOffice some years ago. I fear to lose them 
again - not so much for me, because I have an alternative Microsoft Office 
add-in, but for OpenOffice in general.

An incompatible change for gaining nearly nothing and losing very much is just 
a bad idea!

Kind regards,

Hans Zybura

Hans Zybura Software
Waldquellenweg 52
33649 Bielefeld
Fon: +49-(0)521-9457-290
Fax: +49-(0)521-9457-292

> -----Original Message-----
> From: Juergen Schmidt [mailto:jogischm...@gmail.com]
> Sent: Friday, January 18, 2013 7:16 AM
> To: api@openoffice.apache.org
> Subject: Re: Incompatible change for extensions
> Am Donnerstag, 17. Januar 2013 um 23:19 schrieb Rob Weir:
> > On Thu, Jan 17, 2013 at 10:02 AM, Jürgen Schmidt
> <jogischm...@gmail.com> wrote:
> > > On 1/17/13 3:00 PM, Bernard Marcelly wrote:
> > > > Message de Jürgen Schmidt date 2013-01-17 13:19 :
> > > > >
> > > > > I disagree, the old mechanism is a design bug and should be
> > > > > resolved. It was always planned to fix this a major release. Now
> > > > > with 4.0 we can make such changes and we had long discussions
> > > > > about incompatible changes for major releases. Extensions can be
> > > > > easy updated and by the way it is always a good idea to add a
> > > > > max version dependency and release a new version of your
> > > > > extension if you have ensured that it works with the newest
> > > > > office version. How many unpublished API's are used in extensions
> that can change at any time?
> > > > >
> > > > > We probably don't have enough time to fix many more design bugs
> > > > > in the API for 4.0 but this one is definitely worth the change.
> > > > > We will document it and the fix is easy. But for all new
> > > > > extensions the usage is much more intuitive and less error prone.
> > > > >
> > > >
> > > >
> > > > The current mechanism is not a design bug (because it works),
> > > > rather a clumsy design.
> > > >
> > > > To create a toolbar with the same name in Calc, Draw, Impress, you
> have to:
> > > > - create one WindowState xcu file
> > > > - make 2 copies of this file
> > > > - modify one line in each copy
> > > > - add entries for these files in the manifest.xml Is this really
> > > > complex, error prone ? I don't think so, compared to all other
> > > > features of an extension.
> > > >
> > > > About max version dependency : application developers don't see
> > > > the future. It's not possible to know in advance when (and why) an
> > > > extension will become incompatible.
> > > >
> > >
> > >
> > > exactly and that is the reason why I would today add a max version
> > > dependency always. I know 4.0 will be next, I would change the max
> > > version dependency to 4.0 after testing that everything works and
> > > would do a micro release if I change nothing else.
> > >
> > > >
> > > > In the context of a company that has created a specific extension,
> > > > happily used for years, Apache OpenOffice 4.0 will be a bad surprise.
> > > > Releasing a new version will be difficult: the original developer
> > > > may have gone, or have forgotten the building details of an
> > > > extension; a new developer has to learn the syntax of an oxt file,
> > > > and find out what has to be changed to make it work again. Costs,
> delays. Benefits ? None.
> > > >
> > >
> > >
> > > This would be a situation that is always bad. If you use
> > > unmaintained code you can run always in such trouble. In this
> > > specific case the oxt can be changed easily and the Addon.xcu can be
> > > adapted, repackage the oxt and that's it. No real code changes and
> > > you don't have to remove any XXXWindowState.xcu if you have one.
> > >
> > > I would love to have much more time to fix API design bugs or change
> > > some bad API's to make the life for developers easier in the future.
> > > I was a big fan of compatible API's but learned over time that good
> > > API's have to evolve over time. We didn't do that and the API is
> > > often not easy to use and to understand in many areas. We can
> > > improve a lot here but probably not compatible. I have a mixed
> > > feeling about it but believe that it will help us to make the product 
> > > better
> over time.
> > >
> > > This is an easy change, other API changes that require real code
> > > changes will be more difficult to communicate.
> > >
> > > As long as we communicate and document these kind of changes and
> > > provide migration paths we are on a good way I think. We have to look
> forward.
> > >
> >
> >
> > So speaking of communications... What's the plan?
> >
> > If we're really going to make incompatible changes, we should probably
> > do more than put it in release notes or Bugzilla. It should probably
> > go into a blog post, with advance notice and a link to technical
> > details.
> >
> >
> we will document it in the wiki with a detailed migration plan. Once we have
> this in place we will reach out to the extension developers. Release notes is
> one obvious thing but  a detailed blog post another one. We can ask
> Sourceforge to spread the new via the extension repo as well.
> >
> > How many month's notice would be enough? Can some update before a
> new
> > release? Or would we need to provide a "beta" SDK?
> >
> >
> we can start the communication asap when we have the docu in the wiki in
> place. We don't need necessarily a SDK for this. But the changed samples are
> part of the snapshot SDK.
> The change is really easy and no big thing.
> I am planning a blog to talk about extension and the best way to maintain
> them over time.
> Juergen
> >
> > -Rob
> >
> >
> > > Juergen

Reply via email to