From the demo I saw, it worked as well as watching 1080p YouTube in a third world country. Someone figured it was smart to do server-side rendering and load your document as tiles using a technology designed for maps (the same as used in OpenStreetMap, and there it works well, because that's actually a map and not a document). The person argued WiFi was bad, but when typing on a 100mbps symmetric connection there was still a noticeable delay between my keystroke and it appearing on screen.
Edit: to everyone saying they also can't watch YouTube 1080p without lag/buffering/whatever: perhaps it's not perfect anywhere outside the third world, but I could imagine that there it would suck even more. It's just a comparison, not a research paper.
I suspect that latency can be reduced significantly by limiting tile sizes. They currently use 256x256 tiles, forcing a new tile transfer every time a mutating user action takes place (e.g. a new character typed). A one-size-fits-all tile is unlikely to satisfy users of varying bandwidth and latency tolerance.
Of course, further steps can be taken as well, such as adaptive resolution and client-side rendering extrapolation. Personally I commend them on a bold strategy. At the very least, they will have contributed to the body of alternative web application architecture patterns.
I regularly use Microsoft Remote Desktop in full color mode over 3G from the UK against a machine hosted outside Paris, as an example of what's possible given enough effort, RDP is a bastion of pure awesomeness. I have on many occasions failed to notice I'm running gvim on the remote box compared to a local VM on my laptop. In full screen mode they're practically indiscernible if you aren't paying attention to the latency of your keystrokes. It's impressive enough that on a high bandwidth low latency connection, even small YouTube videos play well.
RDP is heavily integrated into the OS, I'm not sure where it derives its advantage, but for example, dragging a window across the desktop (requiring massive region dirtying) is somehow almost flawless. For example it might be quite an easy affair to delegate compositing and blending to the client, such that the client has a full copy of the bitmaps being dragged around the screen. VNC is intentionally stupid by design and nothing like that (it hails from an era when a microcontroller was preferable for cost reasons compared to a computer in some hypothetical X terminal design - remember VNC is from the 90s).
There is a ton of stuff Libreoffice can do this in this department to produce a compelling solution, alpha quality "release early release often" editions shouldn't be used to form a long term judgement, especially when examples of better implementations already exist, and there is real money on the table to motivate further innovation.
RDP doesn't have to be heavily integrated into the OS. VirtualBox uses RDP for remote display of guests regardless of OS [0]. There are a number of servers for Linux that implement RDP.
Yes, RDP is almost certainly a perfect superset of the VNC model -- unless VirtualBox's graphics drivers do tons of magic, chances are high that all its RDP server has to work with is a constantly changing bitmap to send differences for. AFAIK (and from anecdotal experience) Windows RDP beats that by a long shot (e.g. can preserve the semantics of Bitblt GDI calls and suchlike)
It's pretty unpleasant to use for me too over an ordinary office internet connection: there's noticeable lag for simple UI actions, and there are image compression artefacts when things change quickly on screen.
This also means that it is expensive to run this service, you can only do so much server side rendering per server, much much less than you can response to REST API calls with a little bit of JSON data as both Google Docs (and our service http://Clara.io do.)
This ownCloud service is bound to stay smallish until they embrace a true client side rendering approach.
> This also means that it is expensive to run this service, you can only do so much server side rendering per server,
Of course there is a limit but for the personal use it should not be a issue, for the enterprise use it still should not be issue because it has caching mechanism and server only renders changing tiles, and a 16 core machine easily can handle hundreds of simultaneous users which is cheaper to operate than buying license for the any other office suite per user and employing a IT worker to install that office suites and maintain company wide document sharing.
> This ownCloud service is bound to stay smallish until they embrace a true client side rendering approach.
there is already client side rendering solution in ownCloud called Documents and uses webodf, but it only satisfactory for the simple needs.
I though Europe had much better access to fast and cheap Internet compared to USA? Lowest offering from my ISP is 100/10 for around $16. No problems with HD video. Especially not with Youtube's interpretation of HD.
Europe is made of many independent countries with different regulations and different operators.
In France it's €30 for triple-play, €20 for Internet only, but less than 50% have access to optical fiber. For more than half it's still ADSL. It works great if you live close to the telephone exchange, otherwise it can be very slow.
Grouping is a habit common by Americans, that I am still not able to grasp. They say Africans, Arabs, Asians, poor countries, third-world countries, Europe, Asians, etc. I specially hate it when they say I went Africa and now "The Muslims" all thrown together in politics, ugh.
To those claiming that Office 365 somehow promotes web apps as your real apps... that isn't entirely true.
My company (the one I started, hi) uses Office 365, and all three of us use Office 365's full office suite, the actual real desktop app one.
What we use Office 365's cloud stuff for is their Exchange cluster (oh God, so delicious), and for OneDrive for Business (ie, what used to be Sharepoint).
Browsers just aren't fast enough to handle web apps that large (not picking on Office 365's web apps, anything that big just sorta murders browsers), and I don't think they ever will be. This isn't something you can solve when your only tools are HTML, CSS, and JS.
I've been pleasantly surprised with the online versions of Word and Excel in the past year or so. I don't do anything fancy with them, but it actually feels like a nicer experience than firing up the desktop versions - I do try to keep all my docs in OneDrive, which helps.
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.
They're basically killing Lync and making a combined Skype client that can log into multiple "Skype" accounts, including what Skype for Business is (aka Lync).
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).
I can't imagine that they would dump the SIP protocols that they are using now for Lync/Skype For Business - there's an enormous amount of work invested both by them, and by Plantronics, Avaya, Cisco, and all the other VOIP-phone vendors.
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.
This is a mistake I've seen MS make twice. First, it was OneDrive and OneDrive for Business - they're actually completely different products, and you might remember the outcry around here a while back when it was discovered that OneDrive for Business adds metadata to XML files. A lot of people didn't get what product was really being discussed.
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.
Skype for Business is a completely different product than regular Skype. I'm going to bitch until they give some sort of API access to LyncOnline/Office 365, because it makes my day job writing extensions for it more difficult, but as an IM platform and Gotomeeting-esque screensharing tool it's actually quite good. It's not terrible as a softphone, either, if you are making calls between or within federated Lync/Skype environments. Administering and deploying it is kind of a PITA (just look at some of the architecture diagrams[1], or try to set it up as an on-prem/cloud hybrid...), which is why Office 365 is really taking off, but I'd say it compares favorably to IBM's out-to-dry SameTime, or any of the XMPP variants I've encountered.
That's what I'm complaining about, MS keeps taking two different products and giving them the same name. :)
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.
Actually, the product I got hired out of college to work on was a store-and-forward extension for OCS 2007... It was a nasty inherited mess of SIPScript and mostly broken UCMA 2.0... It's possible to do, but not easy.
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.
It honestly makes no sense whatsoever. It caused massive confusion in the business I last worked in as users constantly opened Skype, and not Skype for Business.
> I've been pleasantly surprised with the online versions of Word and Excel in the past year or so. I don't do anything fancy with them, but it actually feels like a nicer experience than firing up the desktop versions - I do try to keep all my docs in OneDrive, which helps.
That may be because you only use a subset of Word features ? Have you tried the classic Wordpad ?
Wordpad is kind of in that no-man's-land between NotePad++ and doing heavy-lifting with Word.
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.
+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]
I bought Office 365 so I could have full MS Office compatibility while I'm using Linux (not saying LibreOffice is bad, I just sometimes need perfect compatibility).
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).
I don't understand why you're complaining the web app requires it to be in OneDrive first: this is no different than Google Docs requiring it to be in your Google Drive first.
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).
I don't see it as him complaining about the OneDrive requirement per se, but about how that means that since OneDrive doesn't have a Linux client, he's forced to use the web interface, which then forces him to suffer through repeated attempts to try to get him to download OneDrive clients even though platform isn't supported.
If you're running Windows 10 I would suggest checking out the Office "mobile" apps in the Windows Store. They remind me of the clean simplicity of google doc's webapps quite a bit.
Although you're not wrong. Excel is the killer app.
Word is ALSO the killer app for heavy lifting writing papers etc. It's the program I suffered the least in during my uni years, and I tried them ___ALL___.
As an investment analyst for VC, I also need to make A LOT of powerpoint presentations. Not a lot of slides, but I need to convey complex points in a short amount of slides. This makes me push Powerpoint to its limits and it also comes with no REAL competition elsewhere, I've tried __every alternative__. Nothing comes close to the robustness of MS Office, unfortunately.
I would pay full price for native adobe tools on ubuntu - especially now with the subscription pricing. My excel needs aren't as big and have mostly been covered by sheets in google docs. But that's personal need; I absolutely agree that excel is a beast. I've seen some amazing things put together by teams of "non-programmers" (in the professional sense) on excel.
Is there still not a reasonable quality, open-source browser based 'office' app? Open Document is all XML right, so it's not like a browser can't read/write the format because its some binary blob..
I never knew about this until now. That looks pretty amazing and I can see all sorts of potential.
There's all sorts of debate above about office 365 (some reads more like slick advertising astro-turf - people really shouldn't bite at that stuff) but this could be great for many web based business automation apps. I can think of a few things I've done in the past this would have been great for. I see it's already being built in to Zafara and Roundcube.
Etherpad (http://etherpad.org) is an OSS cloud document editor app.
It has a pretty reasonable set of formatting, revision, and
import/export options out of the box, and also a large set of plugins
(http://static.etherpad.org/plugins.html). Supported import formats are
plain, doc, docx, odt, rtf, and html.
There's a demo on the homepage that runs on Sandstorm.io, so you can
very easily self-host or use managed hosting via the Sandstorm framework (https://sandstorm.io).
EtherCalc (https://ethercalc.net/, not related to Etherpad) is an OSS
cloud spreadsheet app. Demo on homepage, also available on Sandstorm.
Sandstorm has several other office/productivity apps, and in my
opinion, is the clearest route to an effective OSS cloud office suite.
I am hopeful for LO Online, but tile-based rendering seems like a bad
choice. I have no doubt it will be packaged for Sandstorm at some
point, but Etherpad is looking much better as of now.
In principal I like this idea a lot. Office as a Service but in freer...sign me up.
As an aside I use LO as sort of a middleware for document conversion via PyOO (start headless LO, convert/load/creat documents etc. via Python script). I think UNO is rather complicated to use at least I struggle everytime I try to read the documentation (possible that I'm too dumb). I hope LO as a service helps make this use case more interesting and thus leads to more documentation and PyOO like libraries.
I feel like there's some potential to get LO into more widespread use by improving/advertising the "headless LO" more.
Oh I'm building this webservice...yeah sure upload your files as Excel or Calcs...we can use that and create nice Calc documents from either one.
Powered by LO.
If you are interested in document conversion using LO and python you can give it a try to https://github.com/xrmx/pylokit which is a python cffi wrapper for the stable api of LibreOfficeKit.
I quit using Microsoft Office over a decade ago. The last few years, I relied on LibreOffice but couldn't stand the regular crashes, bugs and overall frustrating user experience.
I gave Google Docs another go and I must say I was surprised at how much better it was from 3 or 4 years ago. It was good enough for me to consider using Google Drive; me and my team are now using it for everything and couldn't be happier. We actually ditched Dropbox in the process.
Box, Dropbox, Microsoft and other players in this segment of enterprise productivity software should be worried. I'm happy to pay for it and wouldn't run a company without it.
I think a LibreOffice SaaS would have a hard time competing on features with Google Docs, let alone price.
My company did this back in 2000 using StarOffice which was the precursor to LibreOffice (via OpenOffice). Some screenshots[1]. What's interesting is that the numbers don't add up - it's hard to make a profit even at high subscription rates when you have to pay for all the hardware involved. Anyway, I hope they know what they're doing.
Previous news reports posit this work as part of Collabora's deal with .gov.uk.
The thing they're offering up is a downloadable VM for you to play with. Something you could actually set up an in-office version of; something that people can use and report bugs on.
Not sure how easy that would be. Emscripten converts C/C++ code to Javascript, but LibreOffice is written in Java.
Theoretically it should be possible as Emscripten actually converts LLVM bytecode to Javascript, and you seem to be able to convert Java bytecode to LLVM bytecode, but Emscripten's [portability guidelines](http://kripken.github.io/emscripten-site/docs/porting/guidel...) seem to say that you cannot compile multithreaded code, which I assume LibreOffice does use...
LibreOffice is written in C++, actually. There are some small components written in Java, but they're optional, and you can run LibreOffice on a system that does not have Java.
Ah, I learned something today :-) I must have been mistaken because Open Office was always insisting that I install Java for it to work, so I guess I misremembered. Thanks!
As a Linux user, I really like the web versions of the Office365 apps. The functionality is good for situations when I need to work with other people's documents and not taking up disk space for installed apps is a fine feature for the new world of SSD storage on laptops.
I also find Google docs handy to use, even though I use markdown stored in the cloud for writing my own content, managing research notes, etc.
I like the idea of being able to self host cloud services but ownCloud and LibreOffice face stiff functionality competition.
It's a bit sad to see LibreOffice struggling to maintain relevance when the market it tried to address suddenly became [nearly nonexistent] irrelevant.
It reminds me of all those hundreds of early 20th century battleships that suddenly became completely irrelevant when the Dreadnought came by.
[Edit: replaced nearly nonexistent with irrelevant to make my point clearer]
>It's a bit sad to see LibreOffice struggling to maintain relevance when the market it tried to address suddenly became nearly nonexistent.
If you mean that we've moved from desktop office apps to cloud-based Office apps that's absolutely not true.
The numbers I've seen for Google Docs etc are insignificant compared to office workers using MS Office and the rest. People who think Cloud docs have "won" apparently don't share the sames experiences with 99% of office workers in enterprise/businesses/governments etc.
In startup-land and small web businesses yes, cloud docs do well, but those are insignificant numbers-wise to the millions upon millions of classic office workers.
LibreOffice might be irrelevant, but that's because not many care for a free/open source office suite that's not MS Office, not because we've moved to Cloud documents.
This is true. However, the cloud is part of Office 365's ecosystem play. You get the full-strength Office programs installed locally (Windows and Mac), plus the ability to work in the cloud, plus the mobile apps for Windows, iOS and Android.
Even if "99% of office workers in enterprise/businesses/governments etc" do their work on the desktop, there's still some appeal to being able to get what you want where you want it. This is where LibreOffice is trailing badly (as is Google Docs).
>> there's still some appeal to being able to get what you want where you want it
That implies most companies are willing to trust their business secrets to the cloud. That isn't what I see happening, not in medium sized business or enterprises.
> Do you believe that will be the same 10 years from now? 15? It takes a lot of time to change an installed base, but that ship has sailed already.
Try working with a 200 MB document in Google Docs or Onedrive .Do you really think people that have to work 8 hours a day on such documents can afford a web app being slow and unresponsive ? There will always be a place for native apps. Yes the web is getting better, but it certainly didn't deliver its promise when it comes to replacing desktop apps, or PC games or whatever.
Oh yeah, there will always be a place. But that's not what really matters, but the size of that place. Cloud-based productivity systems can replace native apps for over 90% of all corporate functions (marketing, HR, sales, etc.).
Sure, you'll still need native systems for a few heavy functions (finance will keep on using excel for quite a while), but most of the use cases don't need a full-sized productivity suite.
>Oh yeah, there will always be a place. But that's not what really matters, but the size of that place. Cloud-based productivity systems can replace native apps for over 90% of all corporate functions (marketing, HR, sales, etc.).
Or that's what those that built them think.
Then they found out performance and latency make it a non starter, and those "10% of features" that people use from Word, Powerpoint etc, are not the same 10% of everybody, so minimal web based replacements wont cut it.
I haven't used a desktop document or spreadsheet in years. The argument that a couple of missing features, or ones that are somewhat sluggish over a bad network connection, will prevent widespread adoption of cloud-based products is completely ignoring the huge benefits of cloud-based systems.
In short: Calling Google docs a "non-starter" seems like a difficult position to defend. It's already in use by millions of people, daily, and growth is high. There are plenty of folks, including businesses, who have opted not to install MS Office and instead use Docs for everything. Sure, there are plenty of situations where that doesn't work, but as the "web as a platform" advances, and as office products on the web advance, the reasons for sticking with installed apps will continue to decline.
There will continue to be need for installed applications for heavy users for a long time to come (nobody is suggesting serious video or audio editing online, yet, but image editing is already reasonably do-able). Text-based and number-based documents? Those are easy. The very first personal computers could do them pretty well (Visicalc and WordStar, among others), and the web as a platform is vastly more powerful than the Apple II, C64, or IBM PC, that ran those products. And, they're also very easy to work on over very slow connections; you download the whole doc and check in changes in the background. Effectively making all the work happen on the client-side. No big deal.
It's a non starter in many use cases. There's no support for ODBC so you can't connect your spreadsheet to the internal BI servers, conditional formatting is really weak in Google sheets (no data bars, etc.), you can't have spreadsheets that refer to other spreadsheets, docs has awful formatting options, etc.
It's just the same thing as comparing nano to emacs/vim. Sure, they both superficially edit text, but that's where the comparison ends.
OK, so it's not competitive for some use cases today. Nothing prevents implementation of any of those features, or an evolution away from needing those specific features and replacing them with other features. You mention ODBC, which is a cool feature for some folks, but desktop spreadsheets can't readily hook up to a form on the web, which Google docs can. There are powerful new functionalities provided by web-based apps, and in many cases, those new functionalities trump the old ones.
To argue that what is true today will remain true effectively forever is to ignore the entire history of computing. Desktop applications won't win in the end. Every time a credible web-based alternative has arisen, it has won and destroyed the old way of doing things. So much so that we forget old ways even existed. In a decade I'll be surprised if there is still a desktop version of Office even still in development. There will be web-based versions that work without Internet access, but there won't be a version you "install" on your client machine. I'd bet it'll be sooner for most people, but there will remain outliers for several years beyond which there is a good business case for sticking with Office installed on each users machine.
Nothing prevents implementation of any of those features, other than the fact that browser platforms don't allow some basic features to work.
Copy paste? No, not without Flash. Calendar notifications that work when the browser is closed? Custom fonts? Vertical text? Software that doesn't rot? Accurate page layouts?
If these new functionalities were so good and browser integrations were so powerful, then phones wouldn't need app stores, GMail/Google Docs wouldn't have a mobile application, etc. I'm more than ready to bet that in a decade, there will still be a desktop version of Office.
What? Of course copy paste works, even with formatting. Or, at least it does on my machine. Spreadsheets are trickier, but there are ways to override the context menu to make it do-able. I assume Google docs can already do it. Haven't tried it specifically, but I don't remember not being able to...so pretty sure I have copied and pasted within a docs spreadsheet.
"Calendar notifications that work when the browser is closed?"
Why would your browser be closed? This is the future we're talking about. Your desktop and everything else will be in your browser. That's like complaining that notifications don't work when your computer is unplugged.
"Custom fonts? Vertical text?"
Already possible and covered by standards. Are you using IE10, or something?
"Software that doesn't rot?"
Hahahah. Funny. How's Visual Basic written ten years ago holding up on Win 10? Sure, it probably runs, but nobody wants to use it. Platforms evolve. Standards compliant HTML and JavaScript written ten years ago is still functional. What do you believe is uniquely prone to "rot" about the web platform?
All of the app stores have hundreds of apps built on web technologies. Google has a mobile version, but does not have a desktop version. In fact, GMail (and moreso, Inbox) are much better evidence for the case I'm making (that the web will devour almost every class of software in a decade) than the case you're making (that office software like Word and Excel are uniquely immune to being devoured). Inbox is a better mail client than Outlook. And Docs will become a better doc suite than Office...or somebody else will build one that is (might even be Microsoft that builds it...if they're smart, it will be).
> Sure, there are plenty of situations where that doesn't work, but as the "web as a platform" advances, and as office products on the web advance, the reasons for sticking with installed apps will continue to decline.
This is true, but it doesn't have to be one or the other. Office 365 lets you have full-strength desktop programs as well as web apps and smartphone apps, at one low price.
This may be why Office 365 seems to be growing faster than Google Docs, and why it has overtaken it, according to one survey. (1)
Of course, there are other considerations. First, most real businesses need something much more powerful than today's web apps. Second, Microsoft Office is a programmable platform with a huge range of third-party add-ons. Third, a lot of big companies have two decades of Office programming and Office documents. Even if they really want to move everything to the cloud, they're going to run hybrid and in-house cloud systems for a long time....
I'm not implying the web-based solutions are the only which will exist in the productivity suite market. But they are where the mass market is moving to. Native suites will still exist in niche cases, but they will have a very hard time competing with lightweight, low-overhead web-based suites.
>I'm not implying the web-based solutions are the only which will exist in the productivity suite market. But they are where the mass market is moving to.
Any actual evidence for this in the Office suite space? Because I don't see it happening at all. It was an empty promise of 5-6 years ago, same as "Year of the Linux desktop" never came to be.
For mail and collaboration (Slack, Jira, Asana etc), sure, web solutions will prevail. After all those things are all about the social, collaborative features the web brings to the table.
Sales and marketing are often heavy Excel users from what I've seen. Even with the uptake of Salesforce (seems to be used more and more), you still have lots of Excel users. HR is usually a tiny bit of the company so I don't really find that interesting.
Sure you can, concepts survive, but the companies that implemented them in a certain way don't. Things will move to the server and back probably an endless number of times in the future, and each time, a large score of companies will become irrelevant and die off.
Take pagers, the concept (delivering messages) still exists, but the mass market for dedicated, dumb message receivers disappeared a long time ago, leaving only a few niches.
Any company doing a mass-market, native-only, offline-only office productivity suite is bound to fade into oblivion, unless it changes. And that's the point of my original post, LibreOffice is going exactly through that.
> replaced nearly nonexistent with irrelevant to make my point clearer
I'm afraid your point is still not clear. What's your metric for declaring a market irrelevant?
A conventional office suite is still the solution which is overwhelmingly dominating the market. Maybe look outside your own bubble and bias.
A lot of business will never give away there confidential documents in the hands of third party cloud hosts. (which is the sane approach).
So what's your criteria for calling that niche, irrelevant or even non-existent?
When all the major players are switching to a different market. Sure, the installed base is still conventional office suites, but that's like saying that the car market is still gas-based even if all new cars sold are electrical (hypothetical situation).
http://www.winbeta.org/news/office-365-overtakes-google-apps...Bitglass also found that the share of companies using a cloud application for their productivity suite rose from 28% last year to 48% this year. Their report shows that Microsoft has successfully capitalized on the growth in cloud based productivity suite adoption rates to take the lead from Google.
Oh yes, there will always be a very small niche market for almost any piece of technology. Open source projects never die, they just linger forever on the edges of oblivion.
> The ability to own and administer your files is severely under-rated.
I edited my post, my point was that the market for pure offline office productivity suites has become irrelevant, since the competition now is between a pure cloud-based service and a mix of offline and cloud based service :)
Oh, they can, no doubt about that. And that's what the post is about, trying to stay relevant in a changing market. But it adds a lot of complexity, since it switches from a product to a service.
I still crave for a really nice word processor, spreadsheet, and easy database app (in the style of Access). I've always found *Office a bit rough around the edges.
My partner recently brought home an iPad from work. Word failed to play well with other (MS Word) Office documents, so file exchange and formats are still a complete pain in the neck. I will be using plain text until something better comes along.
The word processor and spreadsheet are rudimentary and the OOXML compatibility is terrible.
My favourite new feature in LibreOffice is the Google Drive integration (a first-class feature in LO 5.1). Because sometimes I need a proper bloody word processor or to read an OOXML doc someone's sent me.
LO Online will be proper LO at the back end, so will be that word processor etc.
I think we can all agree that you're not representative of the market, and to be honest, I'd guess (with no data to back it up) that the majority of readers here aren't as well.
People who would like a product/service and are willing to pay enough (in the required scale) for that product/service to exist.
The current core market for office productivity suites are business, followed by consumer. And I'd bet only a very small minority of those are sticking with plain text files until something better comes along.
I should rephrase that then. The plain text is very portable. And easier to edit and read than RTF. That's not to say that there aren't good RTF editors out there. Even HTML is more readable.
Depends what you want to do. RTF can handle the presentation needs of most simple documents, and most word processors can edit RTF files, including WordPad and TextEdit. It's also very easy to convert RTF to plain text.....
Besides dude. Referring to poor countries as belonging to the third world implies that a second world exist. The second world collapsed with the Soviet Union and does not exist any longer. The preferred nomenclature is developing countries.
> The preferred nomenclature is developing countries.
This term has always reeked of over-euphamism to me. I'm not arguing that "third-world" is any better, but what do I call countries that aren't developing? Right now, "developing countries" is used both to refer to countries that are actually developing (Kenya, for example) and as a polite way of saying "poor countries" (e.g. Somalia).
Seems like we should have a term that doesn't confuse the two. When I hear "developing countries", I mentally substitute an image of the most impoverished areas of our world.
You can use LDC if you prefer (Lesser Developed Countries.).'The Global South' is often used in economics circles. There's no term that is wholly satisfactory.
also, "developing countries" tries to establish an absolute rank and a division between countries. What are you taking into account when you say "developed", money? health? happiness? depending on what you use you'll get way different groups of countries
I would be happy to deep dive on this one, as I several of my 1000-level poltical science courses covered what we think of and how we classify and rank countries.
The most basic thought is to begin at the lowest common denominator. What is it that all countries will agree to when placed into comparison. That is the United Nations Human Development Index (HDI). It contains Life expectancy at birth.
Education index: Mean years of schooling and Expected years of schooling.
A decent standard of living: GNI per capita (PPP US$).
Now from here you could rank GROSS DOMESTIC HAPPINESS, but that is a garbage index if you ask me as a political scientist and a champion of the free world. The top grossing country on that list is a country that imprisons and tortures.
But I gather it makes sense to triangulate the facts from the CIA World Factbook, Heritage Foundation Freedom Index which covers press freedom and the extent of freedom of speech, and a sprinkle of transparency thus the Corruptions Perception Index from Transparency International. Now whether you're east thinking or west thinking you might also want to include another sprinkle of Amnesty International and quantify or qualitatively add its reportings to the mix.
What you will find that the initial HDI gives a pretty darn clear and precise estimate of where you would want to live and where in the world could be deemed as "developing" as in not yet reached the top-end of the list.
This is a scientific endavour, and it is not meant to hurt anybody's feelings.
Also: You can downvote me or upvote me as much as you want. This is how the real world approached this problem.
Edit: to everyone saying they also can't watch YouTube 1080p without lag/buffering/whatever: perhaps it's not perfect anywhere outside the third world, but I could imagine that there it would suck even more. It's just a comparison, not a research paper.