Requesting features for OpenOffice and Office?

By Rick Jelliffe
March 13, 2009 | Comments: 2

Readers who have potential features they would like to see in OpenOffice and Office (or other ODF and OOXML applications) should over the next month (i.e. early 2Q 2009) submit requests to the ODF TC comment list (there is a template) or to the Ecma TC 45 (OOXML) or through your local national body to ISO SC34 WG4 or WG5. In fact, often the best way will be to make contact directly with an amenable committee member or the committee chair, and ask them about the procedure.

Of course, there is no guarantee that a requested feature will make it into the standard, or make it in your preferred form, and you should expect up to three years lag time before you see the feature in products, depending on the standards cycle that the individual product cycles. And vendors may decide not to implement optional features, of course.

But all that aside, if we don't speak up about your requirements, they probably won't be met. Mind reading is not the optimal mechanism for standards development!

In particular, this may apply to you if you have put in a request for an enhancement (or perhaps bug fix) to a product, such as OpenOffice. If the enhancement (or bug fix) relates to what ODF specifies, it cannot really be fixed in the product: the product will attempt to follow the standard.

But we cannot expect the product maintainers to route our RFEs and bug-fix requests to the standards committee: they are not a telegraph service.

Of course, the bottom line about a feature is that it needs to reflect some broad or significant requirement, not a niche one or pet idea. You may have ideas for a version of ODF that is more suitable for cats, but it may not be very compelling for the appropriate committees. On the other hand, a requirement by the defense sector or privacy advocates would be much more compelling.

And running proof-of-concept code helps. Burdening developers with extra features is always an issue, so the less work for developers (i.e. the more work that we do) the better.

You might also be interested in:


True. OTOH, just because a feature is in the document format doesn't mean it's accessible to use in the applications. Consider that OOXML has new citation and bibliographic support, but the Office 2007/2008 API is such that developers prefer to bypass it completely and use their own custom fields. Kind of defeats the purpose of the standard; no?

Bruce makes a good point.

When submitting a requirement, be aware of what the scope statement for the standard is. A standard for a file format is not a standard for the API or for application GUIs, though they of course influence each other.

Getting something into the file format merely creates an opportunity. That is why continued participation and pressure are important: standards work needs patience, especially in the lumbering, painstaking world of desktop application suites.

News Topics

Recommended for You

Got a Question?