Spend some time with VSTO on the client and the OOXML SDK on the server and I assure you that you'll still want to kill yourself. I just spent three months doing this and it was akin to knawing your own limbs off. The Office VSTO API is poorly designed, a mishmash of shims that barely work and are impossible to debug. The documentation is awful and their support teams don't even know how to fix problems. It's also absolutely painful making something work on Office 2097, 2010 and 2013. Its bad news when after a week you start wrapping all entry points to stop managed exceptions crashing office.
Open sourcing stuff doesn't make it magically entirely pain free nor does it make a quality product. This isn't a quality product and neither is the thing that generates the documents you will need to parse (and clean all the incongruous crap) from.
However I expect our Surface 2095 will run Office 2097 and it'll still have VBA jammed in due to some legacy clients moaning that they can't run their financial app in it any more :)
If it survives the VBA-pocalypse in 2030, that is, because it interprets dates with two digit years ending in '/30' - '/99' as referring to 1930-1999...
Both ends equally so. We did a lot of parsing and generation and found a pile of bugs in the SDK plus the thing isn't a deep enough abstraction so you have to break it regularly.
Open sourcing stuff doesn't make it magically entirely pain free nor does it make a quality product. This isn't a quality product and neither is the thing that generates the documents you will need to parse (and clean all the incongruous crap) from.