As an end user, I don't care what format Airborn uses internally. What matters is that I can interact with documents and files sent to me by other people, which are likely authored using Microsoft Office, Libreoffice, and Google docs.
As a developer, I would ideally recommend to look into using a custom internal representation for a document and developing converters that convert between your representation and various formats. This way you won't be hindered by limitations of a specific format.
However, if you lack the resources to develop and maintain these converters yourself, look into the feasibility of leveraging LibreOffice by using a preexisting format like WordProcessingML as an internal format. You can then use LibreOffice to handle the conversion between the various formats you want to support. The downside to this is that you'll eventually outgrow WordProcessingML if you want to support futures not supported by that specific format.
As a developer, I would ideally recommend to look into using a custom internal representation for a document and developing converters that convert between your representation and various formats. This way you won't be hindered by limitations of a specific format.
However, if you lack the resources to develop and maintain these converters yourself, look into the feasibility of leveraging LibreOffice by using a preexisting format like WordProcessingML as an internal format. You can then use LibreOffice to handle the conversion between the various formats you want to support. The downside to this is that you'll eventually outgrow WordProcessingML if you want to support futures not supported by that specific format.