+1 for Office 365. I wasn't convinced until I actually started working at a company that uses it properly. The collaboration features in the native desktop apps work beautifully.
Not having to endure emailed-round documents with multiple competing versions like "Report-Dec2015 Draft v5(FP,PL,KM) (2).doc" is worth the price of entry alone.
I feel sorry for those like the UK government who've been successfully lobbied by The Document Foundation into using open standards, and are now locked in to using one vendor - Collabora - and their proprietary fork of LibreOffice.
Are you seriously using the "lock in" argument against open standards? Is this a joke?
You could not be more locked in than when using the Office 365 suite. It may happen to have some nice feature for now, but there is nothing keeping them from pulling an IE all over again, and you will be completely locked in because of the proprietary format used.
No, not against open standards. Microsoft OOXML is an open format. You might recall it's (controversially) the Ecma, ISO and IEC standard format, and is supported by LibreOffice and OpenOffice. So even if MS did something terrible, the documents would still be editable when everyone switches over to LibreOffice - dependent on how well they've implemented OOXML.
And I'm not even against what Collabora are doing, I think it's very clever. It's an interesting way of hitting back at Microsoft by lobbying for open standards in order to create an alternative solution and a profitable business.
I just don't think LibreOffice stands up to MS Office as a product (yes, I've worked with both) for day-to-day use by normal humans.
As far as I'm aware there are no complete implementations of OOXML other than Microsoft Office, and given the complexity of the specification and the huge gaping holes, it is unclear if it ever will be, or if it is even possible to implement for parties other than Microsoft without reverse engineering large chunks of Microsoft Office.
Until there are other complete implementations, calling it an open format is pretty much a bad joke.
> I just don't think LibreOffice stands up to MS Office as a product
That may be so. But a government has many other requirements than the day to day use. They also, for example, have archiving requirements (with timelines measured in decades) that are hard enough to deal with without the risks incurred of locking documents into poorly documented formats only fully supported by a single vendor.
OOXML is a broken standard.
It is bigger than the PDF spec, which already is ridicoulus.
Also some crazy bugs inside older versions aren't always reflected inside the spec. I've seen documents render differntly between Office 2007, 2010, 2013. Mostly between 2010 and 2013 since 2013 is way more correct than the previous versions, still Microsoft use a compability layer to still have a "correct" view.
Microsoft's OOXML is a joke, no matter who rubber-stamped it. It's effectively the binary Office formats expressed via XML. Any office suite adding support for it still has to include the myriad piles of compatibility hacks they did for binary Office documents. OOXML contains several "transitional purposes only" formats that were obsolete before they ever went through the joke of a "standardization process", rather than standardizing a single format; as a result, anything wanting to read real-world documents in the format has to handle all of those "transitional" formats. And OOXML contains elements like "lineWrapLikeWord6" and "useWord2002TableStyleRules".
OOXML was designed, effectively, to be the easiest possible transition from the binary Office formats rather than being the best possible document standard, or even a good document standard. Direct quote from the proponents of the standard: "OpenXML was designed from the start to be capable of faithfully representing the pre-existing corpus of word-processing documents, presentations, and spreadsheets that are encoded in binary formats defined by Microsoft Corporation."
That doesn't make it a bad representation format for a vendor's proprietary office suite, but it does make it a bad standard.
> the "standardization" process itself was effectively politics, not technology.
All standardization processes are politics, pretty much by definition; defining a spec is technical, agreeing to a standard is political.
Not to say that the standardization of OOXML wasn't a particularly bad outcome, but "bad" vs. "good" is a different distinction than "politics" vs. "technical".
> By contrast, there are multiple independent implementations of ODF.
IIRC, OOXML is implemented by OOo/LO and Google Docs as well as Microsoft Office, the former two are independent implementations from the latter, if not also from each other. (I'm not sure any of those implementations are bug-free as compared to anything that has been standardized, much less fully compatible with each other -- ISTR even the Microsoft one early on had significant reported divergences from the standard.)
> All standardization processes are politics, pretty much by definition; defining a spec is technical, agreeing to a standard is political.
Little to no "defining" went on in the OOXML process, hence my use of the phrase "rubber-stamped". What little did take place seems to have been limited to adding more documentation for dangling references to undocumented bits, such as some of the "compatibility" options.
And no, there should be no "politics" in the agreement to a standard. The standard should be seeking the best solution to a problem, not the one best aligned with any particular party's best interests. No "I'll compromise on this if you compromise on that". And certainly no "let's make sure the people who would be inclined to say no don't get invited". OOXML wasn't just politics, it was dirty politics.
> Little to no "defining" went on in the OOXML process
Yeah, defining a spec often happens outside of, and prior to standardization (refinement of the definition may or may not happen during a standardization process.) A standardization process with little defining can be bad or good, depending on why there is little defining.
> And no, there should be no "politics" in the agreement to a standard. The standard should be seeking the best solution to a problem
"Best" is subjective, and involves balancing concerns which different parties will weigh differently; producing a consensus on that is inherently a political process.
> OOXML wasn't just politics, it was dirty politics.
> The standard should be seeking the best solution to a problem, not the one best aligned with any particular party's best interests.
1. That is a rather idealistic view of the world. Standards are typically set by committees comprised of multiple parties, and all entities have an agenda. Sometimes its self-interest, sometimes it's just something like "all things being equal, we prefer doing things this way", but it undoubtedly influences the outcome.
2. Regarding OOXML, maybe the actual problem could be stated as, "the vast majority of the world's official documentation is in a proprietary format and we want to make it open in a way that doesn't inconvenience the millions of users of the existing files, because otherwise nobody would use the new format." Regardless of whether there were dirty politics, what would the best solution to that look like?
> 1. That is a rather idealistic view of the world. Standards are typically set by committees comprised of multiple parties, and all entities have an agenda. Sometimes its self-interest, sometimes it's just something like "all things being equal, we prefer doing things this way", but it undoubtedly influences the outcome.
Certainly; however, making any such change needs to come with arguments that convince others and drive towards consensus, rather than political machinations to manufacture consensus.
When someone proposes a change software project, they doubtless have some reason for proposing that change. However, projects don't typically pay attention to reasons like "we need this change to support our product", or "this makes our internal processes easier", or "without this change our business model collapses". And they certainly don't accept arguments like "if you ignore what's wrong with this patch, I'll [insert reciprocation here]". A change has to come with arguments for why it's the right thing for the project, not just why it's the right thing for the person proposing the patch.
> 2. Regarding OOXML, maybe the actual problem could be stated as, "the vast majority of the world's official documentation is in a proprietary format and we want to make it open in a way that doesn't inconvenience the millions of users of the existing files, because otherwise nobody would use the new format." Regardless of whether there were dirty politics, what would the best solution to that look like?
Treat the old binary document format and representation as the legacy format it was, without giving it a veneer of "standardization". Add features and capabilities to the existing ODF standard, rather than creating a new competing one; likewise, in the various sub-formats, pay attention to existing standards rather than inventing new ones. Migrate to that format as the native format, not just as an export mechanism. Discourage people from saving in the old binary formats. Provide the rendering engine and parsing code of the old office suite as an Open Source library to handle legacy documents. Provide migration tools that actually cross-check things like pagination with the legacy document renderer, to confirm the fidelity of the conversion; collaboratively improve those tools until they achieve maximum fidelity on all available documents. Then, people can migrate new or edited documents with reasonable fidelity, get perfect fidelity for historical documents, and interchange documents with no compatibility issues.
That would not necessarily serve the goals of any one office suite vendor, but it would help move the world's documents to an open, standard, interchangeable format.
Regarding 1), again that is how things should be, and to people's credit, they make fair attempts towards it. But the real world is messy. As an example, very frequently there are a number of ways to achieve similar results. Then often the argument becomes "why's your way better than mine"? Each party prefers a certain approach because it's better for them
for whatever reason. Hence a compromise must be reached, and this is where the wheeling and dealing begins. This is just one of many reasons why, as dragonwriter said, this becomes a political process.
While the solution you propose for 2) makes perfect technical sense, I'd say it steps too much into "inconveniencing millions of users" territory. Providing tools for migration and checking fidelity are big pain points because it does not fit into their usual workflow, which alone makes it highly unlikely to be adopted. If you wanted people to have minimum disruption, the new format would have to be a completely compliant reimplementation of the old one, and I'd guess it's inevitable that the new standard would look exactly like the old one simply because it's the path of least resistance.
The ODF standard was based off the StarOffice file format. If anyone involved wanted Microsoft to participate, that seems like a rather poor starting point.
Documents in emails for you to review is devastating. I have a client who keeps doing it. The first thing I do is download it, upload it to Google Docs and turn on Suggestion Editing. Collaborative cloud based document editing is such a life saver.
A valid point. In this instance, I know because we use Google Apps and store most other things in it. The email is in Gmail, so the difference isn't really that great when you think about it.
As far as I can tell, there is no way to guarantee a 'secure' delivery of documents via email. SMTP might be used rather than SMTPS and you don't always know what servers handle the email when in transit.
> As far as I can tell, there is no way to guarantee a 'secure' delivery of documents via email.
Well, if neither of you forwards to an external account, gmail->gmail email should be pretty "secure" (against other adversaries than Google, those that have hacked one of your Google accounts, and those that Google cooperate with (if any)).
It's not clear by what you write if someone@example.com is emailing you@gmail.com (And so should know that Google knows all the things), or if you meant that you both use Gmail - or if you use Google Apps, so you already give all your emails to Google, but not in a way that is transparent to the sender (however, if the sender doesn't use any kind of end-to-end encryption...).
Not meant as a nitpick -- just pointing out that for some values of "secure" using a single provider for email can be "more secure".
I suppose the "enterprise" alternative would be to have accounts in cross-trusted AD with client-certificates and use S/MIME for client-client end-to-end encryption. In which case (AFAIK) by default, there'd be the possibility of keeping an escrow key.
(The open alternative would probably be to just use Gnu Privacy Guard)
(Seriously: We use desktop versions of Office apps based on Office 365 but I have not discovered any collaboration features so far. Where are they hidden? Are they compliant with European data privacy and labor law?)
I don't know enough about the admin side, but perhaps it's something that needs to be enabled separately. From a user perspective it 'just works' in our office:
If several people open a document shared on OneDrive, that document is opened in a collaboration mode where you can see others working on it, similar to Google Drive.
A menu appears at the bottom of the screen[1] showing who's editing that file. If you have Lync/Skype for Business, clicking on those names opens an IM to that person.
Re privacy, a quick search shows their cloud services are compliant with ISO 27018 as of February this year[2]
Not having to endure emailed-round documents with multiple competing versions like "Report-Dec2015 Draft v5(FP,PL,KM) (2).doc" is worth the price of entry alone.
I feel sorry for those like the UK government who've been successfully lobbied by The Document Foundation into using open standards, and are now locked in to using one vendor - Collabora - and their proprietary fork of LibreOffice.