openoffice-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hans Zybura" <hzyb...@zybura.com>
Subject RE: Incompatible change for extensions
Date Tue, 22 Jan 2013 11:14:39 GMT
Jürgen,

> 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 well.

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 think.

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 so!


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 dependencies.


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:jogischmidt@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
> <jogischmidt@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



Mime
View raw message