Microsoft opens Office binary file format specifications
- 📅
- 📝 127 words
- 🕙 1 minute
- 📦 Microsoft
- 💬 6 responses
Microsoft have released the binary file format specifications to their Office suite (the XML ones are already published) under their Open Specification Promise.
I am not a lawyer but as far as I understand this means you are free to implement the standards with a promise that Microsoft will not use any patents under its control that are required to implement the specification against you.
Hopefully Apple will now address Keynote’s PowerPoint support bug so exported PPT’s works with Office 2007.
Now that the .NET Framework 3.5 source is available (for reference) and Scott Guthrie (now VP) announcing the MVC framework will be user-buildable and patchable (not re-distributable) and include project templates for a number of open-source testing frameworks the future is looking very rosy.
[)amien
6 responses to Microsoft opens Office binary file format specifications
I think you’re right when it comes to consumers, but developers should be capable of keeping on top of this kind of thing, IMO. Or, at least they should have the choice — that’s really what we’re talking about. I guess it’s perception — at this stage I personally would hate to go back to a situation where I have to wait for a central source to address a feature that’s really important to me. I’ve just gotten used to the fact that I can go ahead and solve the problem myself, or more likely collaborate with a few others to do it (our problems are rarely unique). Sure, I may have to adapt to a slightly different implementation later on when the centre addresses it officially, but at least I have the option of going my own way if I want. That genie is out of the bottle for me now, and there’s no putting it back.
The problem there is you are assuming that Microsoft’s customers understand the open/patch/release cycle associated with open source.
Whilst I’m sure many will such as those you interact with on blogs, conferences etc. he fact is there are plenty who haven’t gone near open source and may not (yet) understand this methodology and blame Microsoft software for incompatibilities when some developers/articles/components require a modified version.
It comes down to knowing your customers and when that base is as large as Microsoft’s I can imagine that is a difficult task.
The other thing is — so what if there are multiple versions in circulation? People who are risk-averse will just stick with what MS provide, but if other people want to develop an extended version, they ought to be able to. MS can always fold those features back into the official version if they like them.
MS are still very much of a ‘push’ mindset, where they are the centre of the universe and push things out to others. They’re realising that’s putting them at a disadvantage versus more open models, which is why this kind of thing is starting to happen. But they clearly don’t quite understand the model yet, or why it works, or they’re still a little scared of embracing it. But, they won’t get the full benefits of it unless they do go the whole hog, since the reasons why it works are all intertwined. You can’t pick one aspect of it (give people the source) and expect all the benefits to fall out, things like decentralised control and iterative, experimental external variations are all key to the model working at optimal efficiency.
“What they are trying to do here is to make sure there isn’t multiple versions of the MVC framework in circulation.”
Yeah, but define ‘circulation’. What if someone gathers patches up together into a ‘test’ version to make it easier for other people to test and collaborate on? That becomes a distribution by any other name. The trouble is that you can’t have open-source style collaboration without the ability to redistribute — you either let go control or you don’t. You can’t fudge a middle ground here. If they’re worried about fragmentation, they shouldn’t be — forking is usually the last resort in any project and just reflects that the central devs aren’t satisfying their users. Being able to fork is what gives users the confidence they have a last-resort option should things go bad, but they generally won’t do it. This is another example of MS not entirely grasping the open source principles yet, they’re dipping their toes, but eventually they’re going to have to choose whether they jump in properly or not.
I don’t think there is anything stopping you redistributing your own patches in some sort of diff format.
What they are trying to do here is to make sure there isn’t multiple versions of the MVC framework in circulation.
With time who knows maybe they’ll get it up on CodePlex and do regular scheduled releases especially given the advanced-user scenario it addresses.
Hey, that’s pretty cool. Very late, but cool.
I haven’t read the specs but I hope they’re better than the OOXML ones were, which had implicit holes like specifying behaviour ‘consistent with application X’ without actually specifying what that was. Maybe these specs will help their OOXML standardisation bid, since many of the references in that spec were to existing Office behaviour which was unspecified and the patent situation for it unknown.
It’s good that MVC will be user-buildable too. Shame about the non-redistributable angle, this effectively means each person patching will be operating on their own and unable to collaborate, so you won’t quite get the open-source effect.
IANAL but this makes me feel better about OOXML at least and .Net in general. Now, if only someone other than MS would provide a fully functional, competetive server runtime for it…