The one thing they really need to work on, for me to be super happy, would be their Lync/Skype platform. Either overhaul the old Lync 2013 client that they did a quick Skype reskinning on, or provide a decent API that could be used with Office365, like what they have for on-prem instances with UCMA. Lately, I've been having better luck using the open-source Lync plugin for Pidgin than with the official Lync client - lots of weird things like presence not updating, contact lists getting borked, memory leaks with the client causing crashes, etc.

Its part of their complete rewrite of Skype (that started with the Windows 10 combined Skype/messaging app that is currently in semi-beta that came out with Threshold 2).

As of Skype for Business 2015, it's still SIP - S4B is more of a marketing maneuver than a real technical change. On the server side, applications built to integrate with Lync 2013 work seamlessly with S4B. The S4B client is just a reskin of the Lync 2013 client - it's a minor-minor revision number change, and still calls itself Lync 2013 on its About dialog.

Consumer Skype is still, to my knowledge, what it has always been.

However, Lync has been rebranded as Skype for Business. It's still Lync, and uses all of the same SIP-based protocols that it always has, since it was called Office Communicator.

I still haven't quite figured how they are going to mash the two together, or if they actually are going to. It is confusing having two completely different Skype clients on your desktop.

Now it's Skype and Skype for Business. S4B is a steaming heap compared to Skype in terms of features, and I think in the end consumers are going to end up confused and angry about this new Skype that doesn't have the features of the old one.

[1] https://technet.microsoft.com/en-us/library/gg398095.aspx

I have major problems with Lync/S4B's IM implementation. The most obvious are the lack of store-and-forward for messages to offline users and the poor to nonexistent support for persistent chat rooms (my solution: a "conference call" that's been going for weeks without anyone having turned on the audio). It's also very bad at handling changes in network connectivity, docking/undocking my laptop drops me from IM for at least a couple of minutes and often requires a restart of S4B.

I will agree that the softphone support is pretty good, but it's non-interoperable with our VoIP environment so it goes almost entirely unused. Unfortunately this has been the case everywhere I've worked except for one place that had WebEx and Cisco phones - those would get along with each-other sometimes if you were lucky, but it wasn't very reliable.

My point is that I've found the office communications landscape to be a terrible backwater of technology. I dislike Slack but I can see why it's taking off - most of the on-prem options for IM fail at basic IM features while adding VoIP/telepresence options that are non-interoperable and complex to implement and support. It says something that my employer has multiple FTEs dedicated to scheduling and setting up the videoteleconference rooms, because it takes a specialist just to make a call these days.

There are persistent chat rooms available (at least on-premise, if you install the extra server for them - not on Office365, though), but it's a little half-baked.

If we're piling on, there are some other kind of crummy limits, for a large enterprise IM platform. Sending an IM to a large number of recipients is pretty gimped (I believe the limit is in the 100-250 user range), because any chat between three or more users is bumped up into an AV conference. There's limitations on the number both of users who you can subscribe to presence updates, and how many other users can subscribe to your presence.

The client also seems to have some bad memory leaks. Particularly with any kind of extension that makes use of the COM API.

That may be because you only use a subset of Word features ? Have you tried the classic Wordpad ?

Honestly, it it easier for me to slam together an HTML document than it is to fiddle with a WYSIWYG word processor. It's got a higher chance of actually looking like what I want it to, as well.

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.

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.

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.

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.

However that is really really aweful.

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.

https://en.wikipedia.org/wiki/Standardization_of_Office_Open... is worth reading; the "standardization" process itself was effectively politics, not technology.

By contrast, there are multiple independent implementations of ODF.

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.)

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.

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.

On this much, we agree.

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?

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.

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.

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 [email protected] is emailing [email protected] (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?)

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]

(and no, I don't work for Microsoft!)

[1] http://core0.staticworld.net/images/article/2013/04/who-is-e...

[2] http://www.zdnet.com/article/microsoft-adopts-international-...

It looks like this Web based LibreOffice is all available from public git repos[1], so why are you calling it a proprietary fork?

[1] https://www.collaboraoffice.com/code/

I feel sorry you are so ignorant.

That didn't turn out to be a good idea. First of all, to actually open something in the web app, first I have to add it to OneDrive. I cannot add it to OneDrive without actually opening OneDrive on the web because it doesn't have a Linux client. Once I actually open something up, "Install X for your device" just kept popping up (it changed recently).

It's still nowhere near the desktop experience, but I hope it will before July (when my license expires).

Apps loading files off your disk is highly problematic, and these apps are ran at least partially server side (both Office365's and Google Doc's).

This is a feature, not a bug.