almost scared to ask this...

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent

almost scared to ask this...
by Borker on Wednesday 09/Jan/2008, @08:53

...but here goes: if a company requested / paid for the addition of support of various MS formats (existing binary formats, new XML wrapped binary formats aka OOXML), what would the answer be? are there moral / legal / community issues about this?

I think this is great that a company is forming around koffice and I'm really wishing you guys all the best. I'm just asking this out of pure curiosity and not trying to start flame war (which i know are usually the last lines written preceding most flame wars, d'oh)

Related Links

·   Articles on KDE Office Suite
·   Also by Borker
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: almost scared to ask this...
by Inge Wallin on Wednesday 09/Jan/2008, @09:01

I see no reason why paid development couldn't be for legacy file formats.

In a recent dot story the KOffice developers explained that they weren't interested in spending their own time developing it, but that's something completely different to paid development. It is also not connected to any KOffice developer's opinion if for instance OOXML should be made an ISO standard (it shouldn't) or if the file format itself is badly specified (it is) and impossible to implement fully (it is).

[ Reply To This | View ]

Re: almost scared to ask this...
by Borker on Wednesday 09/Jan/2008, @09:18

Thats pretty much my take on it also. Its simply neither expedient nor particularly desirable to implement 3rd party proprietary formats.

I guess the issue though is mainly that the aforementioned dot article was held up by RMS as a counterpoint to the somewhat MS-happy approach of other development efforts and there is a big opportunity for future paid for efforts to include particularly OOXML being presented in a negative light and starting all kinds of flame war fun on the usual tech blogs etc.

[ Reply To This | View ]

Re: almost scared to ask this...
by Joe on Wednesday 09/Jan/2008, @13:47

Wrongzo...

It matters a great deal to implement proprietary filters for *import*.

Export is another story.

[ Reply To This | View ]

Re: almost scared to ask this...
by blacky on Thursday 10/Jan/2008, @00:19

Borker, notice that the KOffice community doesn't necessarly need to merge the work done by this company. I bet they will have a special build for their customers; possibly even single builds for special cases.

[ Reply To This | View ]

Re: almost scared to ask this...
by Hank Miller on Thursday 10/Jan/2008, @06:32

Except that at least half their board is composed of major Koffice contributers. (I don't recognize the names of the other 2 board members, but that doesn't mean they are outside the koffice community, just that I don't know them) While in theory the koffice community could reject their patches, since they are the community this is less likely.

I suppose it is possible they will get paid for an ugly hack that sortof works and meets a customers needs now, but isn't the direction they want koffice to go long term.

Special builds for customers, and single builds are likely. Sort of like Code Weavers has their own version of Wine, but it only better than Wine as a whole in places where they have ugly hacks that make one things sort of work while making others less likely to work.

[ Reply To This | View ]

Re: almost scared to ask this...
by Glen Anthony Kirkup on Thursday 10/Jan/2008, @08:22

Exactly, it's natural for variants of software to exist for different applications. No need for something unnecessary to be added to the main code base.

[ Reply To This | View ]

Re: almost scared to ask this...
by Thomas Zander on Saturday 12/Jan/2008, @06:09

One thing that I kept in mind while doing plugin-interface design for KOffice2 in general and for text specifically is to make sure companies can add their own workflow features without touching the KOffice codebase.
If a company wants to have something like a special variable in text that connects to their internal database (for example), they can write a text-plugin quite easily to do that, again without touching the KOffice codebase. (see the techbase tutorials about koffice plugins)

Since the libraries KOffice provides are LGPL the company may very well choose to make the plugin they want to use closed source. Which obviously means it will never hit the KOffice codebase.
There is a nice incentive for companies to go via KOfficeSource instead of doing it in-house not only because of the expertise, but also because of the Qt licenses required to do this.

Bottom line; this significantly lowers the trashhold for large rollouts to succeed. Any missing thing can now be added by paying the experts to do exactly that.

Exciting times :)

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"I never sing because it upsets our dogs." -- Waldo Bastian
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.