Inside MS, SharePoint is often used to "track" project documents. Start a project and -poof- your most unfavorite PM has creates a procrustean bed of document folders, all set for you to lose your documents in because none of the categories match anything in the actual product. Like, having whole separate doc folders for Beta 1 and Beta 2 (there's going to be a second beta, and the docs are going to be cloned into those? Really?)
PMs: "Please add your documentation to these folders."
Devs: "When we do that, we lose control of the documents, we can't get at the history, we can't search them, we can't even find stuff in there, and SharePoint is slow and the permissions are always wrong, and a year after the project ships the SharePoint will be destroyed and we will lose all of the documentation." [All of this is true, especially the bit about not very old project documentation completely going away, OMFG].
PMs: "We don't care."
Devs: [check documents into the source tree anyway, and write a mirroring script to copy the things to SharePoint]
PMs: "Stop that."
Devs: "We don't care."
The right answer is, of course, to fire the damned PMs who serially insist on a crappy excuse for a version control system despite everyone else pushing back and saying that it sucked hard. Only saw that happen a couple of times.
SharePoint (evolved as Office Server) is a beast of software and many awkward engineering & design choices from the 2003 era are still visible to the end user. And I am not even touching the XHTML tabled based layout with thousands of CSS rules, Silverlight & ActiveX controls, bad WebDAV support, "SharePoint Groups", low soft & hard limits for file size, file count in folders, etc.
It has of course also it good values for companies. Like the Office integration, the Office ribbon UI and some document management options that are missing from Windows Explorer thanks to the failed attempt to release WinFS in the Longhorn era.
Microsoft also discontinued InfoPath, the WYSIWYG form designer that is part of Office 2003-2013 and the InfoPath form services hosted on top of SharePoint: http://en.wikipedia.org/wiki/Microsoft_InfoPath
Will Microsoft rewrite (or refactor) SharePoint and its form services from the ground up? Or will SharePoint 2015(?) be a rehashed v2013? And will Windows 9 come with an improved Explorer and NTFS/ReFS with better document management capabilities like that were planned for WinFS or "Microsoft Semantic Engine"?
The diagram trying to explain how the different APIs relate is a pretty good visualization of the problems that anyone trying to refactor SharePoint would face.
Apps are being pushed hard for all customizations so as to decouple code from the "core" of SharePoint so as to allow for a better upgrade strategy.
That being said, I do see Yammer as replacing a lot of functionality within SharePoint over the next 2-3 years, but I believe SharePoint as a product (especially as it relates to document management and search) will continue to exist for at least another 4-5 years.
It would be better to build something on top of Outlook and Onenote. New file systems will only be useful if the metadata survives email which would require email integration anyway.
Another product team pages evolved from Frontpage server extension. Both products merged to what is known as Sharepoint 2003.
Most of the functionallity is still in Outlook client. You can also sync Sharepoint sites with Outlook and access your document libraries offline.
Kill me now.
The cluelessness and lack of interest from either the IT dept. or anyone really drives me crazy. I just get shoulder shrugs from colleagues when I tell them magical tales from the distant lands of version control.
There's may be a case for pushing hard but I'm leaving in September.
At the current place the only time I even see anyone from IT is when something needs fixing. I can see multiple vectors for real process improvement.
And I think this will be a feature of many IT depts. If you want to make a positive contribution and be known for making a difference rather than being regarded as some sort of Janitor then you need to get out of your chair and, as Taichi Ohno says: walk the gemba. The gemba is the shop floor where things happen and the place where making a difference is something your customers are willing to pay for. Don't be an IT anchor, ramping up equipment costs to stay in place.
It only exists still due to cash back handers.
It sounds like most of your complaints are about the way the processes were managed rather than SharePoint itself.
I notice that management in most companies has a bad habit of believing IT will put up with awful tools just because admin staff do.
"I resemble that remark". Shudder.
Such fun, a web implementation of a 1980s folder system, with no possible way of doing an "ls -lr". One gets to click every node in a three or four deep hierarchy to look for a document. Shudder, erase from memory.
Except SharePoint does store history and you can search it. And no need to create a second Beta1 and Beta2 folder when you can just mark documents as release = Beta1 or release = Beta2.
And getting history out was, to put it mildly, a pain in the rear. Something I could do in five seconds became a nightmare of bad web UI.
Anyway, the devs in my group had a rule of keeping docs in the source depots, and we never lost anything. Poor other groups, we saw them lose important design documents when IT decided that the two year old SP wasn't being used anymore and got recycled. Wow.
Maybe SP does all that whizzy stuff. I just saw it being unutterably stupid, slow and unreliable in practice.
I have seen SharePoint installations at big corporations and they are horrible.
In one case there was a central SharePoint group that has commissioned the sites. So we had a highly restricted, utterly gutted and badly corporate styled thing that was practically useless.
Add to that that there was a weird mix of public and enterprise editions (which cost a bunch of money and were frowned upon by the org unit).
In this environment you can sit back and watch productivity and common sense being choked to death. Enterprise is a weird place.
Every time I've seen share point used, everyone described it the same way. Its where documents go to die.
So far at the current gig a share point "upgrade" has meant that all our fun use of the old install is useless. All of the sudden wikis look more useful.
Burn me once and all that. Oh and search, yeah that search is about as useful as altavista was back in the day.
Will someone please kill sharepoint already?
Let that sink in for a moment.
It does until it doesn't. Just like "Plays for Sure(TM)," also from MS, worked until it didn't.
Are you referring to unintended technical defects or DRM?
By all means. How do they know when they're done learning it? It's by definition difficult to tell the difference between missing functionality and hard-to-discover functionality.
The article is about Onedrive for Business. Which is nothing more than a Sharepoint Document Library in the users MySite. And that is probably also the cause of the behaviour that the autor is describing: there's probably some workflow or other weird SharePoint feature at work, that was installed or activated unknowingly.
The result was that next week, people were setting up ad-hoc fileservers and documentation systems to avoid using sharepoint, with half-baked sync scripts to placate management.
And, I have personally found SkyDrive Pro, or OneDrive for Business, or Groove, or SharePoint, or whatever MS wants to call it, very convenient and reliable compared to Google Drive (for which the desktop app tends to quit every hour and leave things un-synced, and which has far worse web viewers).
So: what collaboration tool would you suggest for the average corporate drone to use? And no, git is not an acceptable answer.
Email + shared folder (as flat as possible) with rigorously enforced naming conventions. Clever features like search can be added with crawlers.
- have workflows, so documents can be approved among other stuff
- have document lifecycle, so they expire and must be reviewed after time x
- solve the Dropbox problem - how do you collaborate with external entities without compromising security by having users uncontrollably put stuff on Dropbox, because there is no other way?
- have automatic versioning
- be able to checkout/lock a file during editing
These are just a few aspects. You can do most if this by gluing stuff together yourself, but these are the constraints:
- be able to achieve all this with semi-competent IT staff
- seamless integration into the existing Windows infrastructure is a big plus
- be able to blame someone else if something goes wrong
So - what do you propose?
To maintain an archive files become read only after 24 hours.
"Doc-456 V-024 Joe Bloggs ✔"
A few years ago I played with SharePoint for a bit and found some good use cases for it. Decided I'd throw some code together that I could wire into it and sell. There was a demand and SharePoint object model was pretty spot on.
4 days later I hadn't even got a bearable working SharePoint installation for doing dev against, had to throw another 4gb of ram at the machine I was working on and wanted to kick the shit out of the thing due to the recursive layers of batshit.
14 days later I had learned python, written the entire thing from scratch using django and had gone live with a client who still uses it today.
It really peeves me to see PMs get away with doing spreadsheet management and wear teflon suits...
To be fair, i've been on a team where the engineers passed the buck towards me also, so i had to push towards written follow ups and detailed documents but that was isolated from the entire team..
Framework filled resumes go straight to the trash or get tossed a cluster f* in an interview to see how they structure the problem and build out a path towards a more productive structure.. most have failed because they all respond with some rendition of 'call a meeting with the team and their supervisor'..
Sharepoint has its origins in managing collections of MS Office documents more so than HTML and browsers. It knows about certain document types and tries to do intelligent things with them. It's not necessarily the tool you would use for serving raw data over HTTP with arbitrary Content-Types. (Given the complex and varied rules by which browsers interpret content, I'm not actually sure how one could even do that perfectly securely short of enforcing separate second level domain names for each and every tenant.)
As an old-school software engineer, we used to say the biggest part of requirements analysis is setting customer expectations correctly. It seems fair to say that the renaming of Sharepoint to "OneDrive for Business" has surprised some folks where it behaves differently from plain OneDrive or from raw BLOB store.
There's your problem right there ....
Please name three nontrivial, commercial, end-user facing apps or services that know nothing about any file or document types.
The only problem is that we are talking exactly about a file synchronization tool. Thus the exercise isn't as valuable as it may appear at first.
The stand-alone OneDrive for Business (formerly SkyDrive Pro) sync client lets users of Microsoft SharePoint 2013 and Microsoft SharePoint Online in Office 365 sync their personal OneDrive for Business (formerly SkyDrive Pro) document library or any SharePoint 2013 or Office 365 team site library to their local computer. This sync relationship provides access to important content both online and offline. The OneDrive for Business (formerly SkyDrive Pro) client can be installed side-by-side with previous versions of Office (such as Microsoft Office 2010 and Microsoft 2007 Office).
I tried the installer. The installation process is branded all over as being a feature of Office.
Is there something other than the substring 'Drive' that gives the expectation of a fully generic file synchronization tool?
I don't think anyone is expecting OneDrive to be "fully generic" (I believe that 'emeraldd was referring to the "tries to do intelligent things" portion of the sentence he quoted).
It just seems that people are unaware of the fact that putting certain kinds of documents into "document libraries" or "team site libraries" involves automatically adding metadata to those documents (from the OP's example, html comments and "xmlns:..." attributes were added to html files).
Namely, AirPlay between OS X devices and iOS devices (including just audio and both audio+video), in either direction. Here's hoping for OS X 10.10.
More correctly "Surface RT" vs "Surface Pro". "Surface" was initially Microsoft's interactive table , so yeah pretty much a branding disaster if we take a walk down the history lane.
I think the idea was to have "one" device (even though there were actually two different devices, with very different hardware) with the name of Surface, but which came in two versions, one with Windows RT, and one with Windows 8 Pro. So they were telling people: "This is Surface with Windows RT...and this is Surface with Windows 8 Pro".
But yeah, a disaster. Their current names of Surface and Surface Pro may be simpler to use now, but it's actually more confusing for consumers, because this current naming implies Surface Pro is basically Surface, but with a few extra features. When in reality, they are very different. I think this confusion was meant on purpose, because they want people to believe that Windows RT is "just like regular Windows - but with fewer features". They are doing their customers a disservice by trying to trick them like this.
Btw, I just noticed that the old Surface is now known as PixelSense. Makes sense.
MSFT (and other companies) have a very bad habit of circular/redundant/superfluous naming conventions.
In this case Pixelsense and the renamed Surface RT never had direct naming overlap.
Wonder if it would modify files in a git repository in the same way? Good luck recovering from that!
I would recommend that everyone keep working copy of their source code outside of any form of syncing. If you must, create tape archives (or 7z or something) and sync them but never your working copy.
As many others have said, OneDrive For Business is really more of a SharePoint + Groove document sharing / collaboration thing for businesses documents (as the name kind of implies). While it does similar things from a generic corporate user point of view, the mechanics are pretty different. OneDrive For Business works well for the same kinds of use cases that SharePoint does (mostly documents), but I wouldn't put source code in there.
Let me put it this way: I would be scared to store an svn checkout because of how svn stores metadata copies. I wouldn't worry about a git checkout.
IIRC the Office Org owns the SharePoint client while OneDrive proper is handled by the Windows Services team.
So I'm ascribing this to incompetence and/or bad judgement rather than malice. But either way, still unacceptable.
EDIT: I see that 'ppog has already mentioned this
I tried Google Drive before and found it unacceptable that it just leaves links to documents on your local disk. I could imagine that in a network down situation I'd be in the shit.
So I'm here with LibreOffice and local file storage only now and all is good.
I don't buy the supposed advantage of these services any more. I'm just going to lump my ThinkPad around and not worry about where my shit is now (it's with me). I'll keep an offline backup at home and one off site (encrypted).
At this point, though, I've personally settled on a system similar to the GP's — a backed-up laptop. In the rare event I need to access a document on the laptop when I've left it at home, there's always ssh, and, in the even more rare case where I need a document and I've left the laptop elsewhere, there's always ssh + rooting around Time Machine folders on my backup server. Finally, for times when I don't want to carry the laptop and know I'll need access to files, GoodReader on iOS syncs over a variety of file server and cloud storage protocols.
 On second reading, I see perhaps you were sarcastic. If so, well trolled good Sir! :-) I had it coming.
ssh firstname.lastname@example.org md5 your/file
ssh email@example.com md5 your/already/encrypted/file
Luckily there exists plenty of FOSS options that provide a close approximation of this functionality for me, though I know they will likely never be an option for the type of companies that rely heavily on things like OneDrive.
That's not a privacy infringement, that just sounds like production code went up to the wrong server.
While I'm happy that Microsoft is re-aligning with reality, I still don't quite trust them yet. They have a lot of credibility to rebuild.