Management
Technology
- Applications
- Business Intelligence
- Development
- Hardware
- Mobile & Wireless
- Networking
- Internet
- Operating Systems
- Security Products
- Servers & Datacentre
- Storage
Toolbox
Training
Books
White Papers
Webcast
Resource Centre
Cracking Open the SharePoint Fortress
September 29, 2009
Posted by: Glyn Moody
If you wanted proof of the continuing ability of Microsoft to find new ways of gaining/retaining control of enterprise software markets, look no further than SharePoint. It's a nebulous product, as the Wikipedia encapsulation makes plain:
Microsoft SharePoint, also known as Microsoft SharePoint Products and Technologies, is a collection of products and software elements that includes, among a growing selection of components, web browser based collaboration functions, process management modules, search modules and a document-management platform.
SharePoint can be used to host web sites that access shared workspaces, information stores and documents, as well as host defined applications such as wikis and blogs. All users can manipulate proprietary controls called "web parts" or interact with pieces of content such as lists and document libraries.
Despite – or maybe even because of – that nebulousness, SharePoint is a brilliant success, for a couple of reasons. In a way, it's Microsoft's answer to GNU/Linux: cheap and simple enough for departments to install without needing to ask permission, it has proliferated almost unnoticed through enterprises to such an extent that last year SharePoint Sales were $1.3 billion.But as well as being one of Microsoft's few new billion-dollar hits, it has one other key characteristic, hinted at in the Wikipedia entry above: it offers an effortless way for people to put content in to the system, but makes it very hard to get it out because of its proprietary lock-in.
This makes it a very real threat to open source. For example, all of the gains made in the field of open document standards – notably with ODF – are nullified if a company's content is trapped inside SharePoint.
Against that background, the following news is important:
Google's new [Sites] API can, among other things, move files from Microsoft SharePoint and Lotus Notes to Google Sites collaborative content development tool.
Signaling an intent to compete with giants in the collaboration software space, Google unveiled an API to extend the Google Sites collaborative content development tool, featuring a capability to migrate files from workspace applications such as Microsoft SharePoint and Lotus Notes to Sites.
One application already built using the Google Sites API is SharePoint Move for Google Apps, developed by LTech for migrating data and content from SharePoint to Sites. Google Sites is a free application for building and sharing websites; it is described by Google as a collaborative content creation tool to upload file attachments, information other Google applications such as Google Docs, and free-form content.
Assuming that I've not missed something here, this new Google Sites API seems pretty big to me: it offers a Get Out of Jail Free card to businesses that would otherwise find some of their content locked away in SharePoint. And once that data is liberated, there are plenty of open enterprise content management solutions out there that would be glad to accommodate it – without the lock-in, of course.
Follow me @glynmoody on Twitter or identi.ca.
Follow highlights from ComputerworldUK on Twitter
Sign up for our Daily Newsletter
The UK IT News widget Get it for your site!
<<newer entry | back to blogs index | older entry>>
Advert
Email this article to a friend or colleague:
PLEASE NOTE: Your name is used only to let the recipient know who sent the story, and in case of transmission error. Both your name and the recipient's name and address will not be used for any other purpose.
- This article is now being printed.
What are your views on this subject? Use the form below to post a comment on this article up to 1000 characters.
Click below to add 'Cracking Open the SharePoint Fortress' to your blog.
If you do not have a ComputerworldUK Account and would like to use this feature, please Register.
If you are a registered, logged-in user, this will post the title and first paragraph of this story to your blog to share with your readers.
Advert
Newsletters
Sign up to our Weekly Round-Up for the past week’s not-to-be-missed news analysis and insight delivered straight to your inbox.
WHITE PAPERS
-
Legal risks: Employee use of the internet and email
Exploring the challenges facing IT Mangers today and vital steps to ensure safe internet an email use by employees. -
Phishing for victims
This White Paper examines the phenomenon of phishing. It explains the potentially catastrophic threat it presents to all kinds of organisation. Exploding some widespread myths, it lights up the murky waters where phishing first emerged and where it continues to evolve. But it also highlights what your business can do to blunt the threat.
About the author
Glyn Moody Glyn Moody's look at all levels of the enterprise open source stack. The blog will look at the organisations that are embracing open source, old and new alike (start-ups welcome), and the communities of users and developers that have formed around them (or not, as the case may be).
Comments received
The truth about proprietary formats is... said on Tuesday, 29 September 2009
If you're still using proprietary data formats this deep into the 21st century, then you either do not create any worthy data or you're negligent with it. More Windows developers are waking up to tying their programs to the whims of Windows APIs.
Glyn Moody said on Tuesday, 29 September 2009
Well, I think a lot happens without people realising it. SharePoint is such an attractive solution for many that it's only later that some of the possible problems are discovered.
Steven said on Tuesday, 29 September 2009
All of the reasons that you cited for Sharepoint's ubiquitous adoption are reasons that Google's cryptic data API will not be a critical factor for enterprise customers.
Cyclop said on Tuesday, 29 September 2009
We're using SharePoint at the company I work for. We're using it for all kinds of list, document libraries and simple processes. Lately we wanted to integrate it with some custom code and shallow scan of the market showed us that it's not easily done and the tools we could buy for that are in the range of thousands or more dollars.
Then we hit upon SharePoint's web services interface which is installed with SharePoint. It is so simple to integrate with SharePoints using web services (and XML) and the .NET interface is so simple that I wonder so little is generally known about it. With this kind of interface, SharePoint can hardly be called a silo and a company intent on taking the data out to some other system can easily do so if they so wish.
Just a comment from the trenches...
nobody said on Tuesday, 29 September 2009
@Cyclop:
only .NET is NOT an "interface". You have to write code to extract that precious data from SharePoint, but no coding is required to put that data in.
If you want something similar to SharePoint, but without the attached strings, try Alfresco.
Daniel N said on Tuesday, 29 September 2009
Is this article an editorial? clearly the author is biased and has never actually used Sharepoint. Sharepoint has many open Apis for moving data around. And whether you store documents in the database or directly on a file server using Sharepoint as the meta data management tool both the files and the meta data is easily accessible and can be "recovered" as this articles so badly puts it. Next time I would suggest the author perform so fact checking before writing something like this.
StuckBetweenARock said on Tuesday, 29 September 2009
There will be/are a lot of organizations that are "stuck" with something like sharepoint because they can't distribute data outside of their infrastrcture.
If Google were to "open" the technology for "Sites", then there would be good competition for MS...
Hans said on Tuesday, 29 September 2009
I use SharePoint in our offices and I don't seem to suffer from being 'trapped'... What on earth are you talking about? By 'trapped' do you mean there's no automated way to push all your content into another content management system? LOL.
Prakash said on Tuesday, 29 September 2009
This article is pure BS. The following 3 lines of code will get any data/document out of sharepoint.
SPWeb web = new SPSite(siteURL).OpenWeb();
SPDocumentLibrary dox = web.Lists["Documents"] as SPDocumentLibrary;
byte[] fileBytes = dox.Items[0].File.OpenBinary();
Follow this link.
http://blah.winsmarts.com/2008-5-CNET_-_please_do_your_research_before_opening_your_big_mouth.aspx
Chris said on Tuesday, 29 September 2009
And Google would be more than happen to search through the documents you submit.
This is completely bogus given that people are complaining code is required to move it, yet code is required to insert into the Google Sites !!API!!.
As the poster below noted, three lines of code gets the data out. Most internal content management systems are internal for a reason. The only reason this should even be bothered with is for anyone looking to move from it because it did not meet their needs, but every company seems to enjoy it.
This is not a case of devious lock-in, but a normal implementation of a system. Any system that wants to transfer from it can implement the same three lines of code (and a recursive looping structure). Pardon me for working in the computer industry and not feeling like that is a problem worth the amount of words used in this story.
Donovan said on Tuesday, 29 September 2009
I have to agree with the posts stating that removing documents from SharePoint is similar to any other content management system. The problem with SharePoint is the ease of creating sites and adding content. When you are a large organization and wish to manage your data and documents in any sort of structured manner, this presents a huge problem. This is especially problematic from a records management perspective. Anyway, the tool looks cool, but you don't need to dog on SP because you have to write code to extract data since that is a common attribute among competitors.
Davey said on Tuesday, 29 September 2009
Can you care to explain how content is 'trapped' inside SharePoint? Lists can be exported and document libraries have explorer views.
SP-User said on Tuesday, 29 September 2009
I'll rag on SP because I've used it more than these people. The lock-in comes from using Office products that are suppose to be integrated with SP. For example the Document Information Panel is only usable with Office 2007 Products.
Excel Services and KPI reporting features are only usable via Excel 2007 XLSX format. Spreadsheets in XLS format would need to be converted to XLSX for this feature to work.
MOSS requires enterprise licenses which are not cheap.
Exporting documents might be easy but the meta data does not come over by simply exporting them. You need to develop an application or buy a program that will migrate the meta data into the new system. Not an easy task.
@Daniel - SP DOES NOT store files on a local file server. Your files are stored in SP (in a MS SQL DBMS ). That's the whole point of SP! Collecting all these scattered documents into one place, eliminating the need for LAN drives.
I use SP. I develop in SP. I know SP. The article was correct.
@nobody said on Tuesday, 29 September 2009
SharePoint exposes functionality through web services and you can use .NET, Java, PHP etc. to upload, download, modify and do whatever you want with your “locked in” data (web services are relatively easy to communicate with as the technology is meant to be used for integration etc. between different systems). In fact, it would not surprise me if google is using these exact same web services to extract your data. I call BS on the author’s article and your comment...
samwyse said on Tuesday, 29 September 2009
I agree with the article. I had a web app running on a Linux server that could have benefited from some data on the corporate Sharepoint server. I spent a week trying to figure out how to automate access to what I needed, with no luck. Obviously, Google figured it out, but I couldn't find any method that didn't involve an intern sitting in front of a Sharepoint screen.
@SP-User said on Tuesday, 29 September 2009
Regardless of the system you use, you will need to write or buy migration software to get your data out of system A into system B. Furthermore, if you agree with the article, then you aren’t a very good SP developer...maybe just a user as your name suggest...
SharePoint supports WebDAV. Not a fortress, not p said on Tuesday, 29 September 2009
It's definitely not a proprietary API. Access is over HTTP using WebDAV. There's also a .NET API (SPSiteDataQuery), which calls web services - you could call them with Java or gSOAP if you want. You can watch it all happen with Fiddler (or your favorite open source HTTP proxy). The XML schema for the web service is retardedly easy. It's riduculously simple to retrieve content from SharePoint.
And for the guy who missed the point of the article and doesn't want to use an API, you can browse, retrieve, and update your SharePoint content from Windows by pointing Windows Explorer at the SharePoint site. It also works on Mac (http://www.atmasphere.net/wp/archives/2006/07/06/sharepoint-through-webdav). All this is non-proprietary WebDAV, so Linux WebDAV clients can do this, too, although I haven't tried one.
SharePoint is definitely not a fortress, and one of it's biggest strengths is that it doesn't use a proprietary API. Google is doing this, but so could anyone else.
Paul Galvin said on Tuesday, 29 September 2009
"proprietary lock-in" is frankly kind of absurd. You can pull data out SharePoint via documented APIs (server side and web services). End users can pull data out using WEBDav (e.g. windows explorer, mapped drives).
In what sense is the data "locked in" to SharePoint?
I don't argue that it's proprietary on the back end, but how do you justify the notion that it's locked in? That doens't make sense. Devs, end users, tools, etc. All can get at the data.
Glyn Moody said on Tuesday, 29 September 2009
Thanks, SP-User: you said what I would have replied if I'd known as much as you...
The lock-in isn't a simplistic kind that you can't get anything out: it's the way SharePoint is so tightly knit together with other Microsoft products that makes for a broader kind of lock-in.
Scott Brickey said on Tuesday, 29 September 2009
Background: I am a SharePoint developer.
Yes, a lot of data is in the SharePoint databases. Yes, it's all accessible (via API's, and Web Services, as simple data and as XML).
The "problem" is that there is a massive amount of data. Files get uploaded, metadata attached (or perhaps *just* metadata), permissions get applied. In some cases business data (ERP systems/etc) get connected. Web Parts for "application page" types of views are created.
This is a LOT of data. It's like taking an Access database (tons of views, VBScript modules, data, etc) and saying "gosh, it's not just a one-step process to migrate"... you're right! it's not!
Obviously people are making data migration/integration pieces for SP... which occurs because the API's *DO* expose the info.
The only problem I tend to see is that at times it's difficult to find all of the pieces, due to the integrated products (have fun figuring out how to access the crawl history which SP integrated from Search Server).
Gov Worker said on Tuesday, 29 September 2009
It's the kind of lock in where you have to create the content in Office 2007 to upload. It doesn't like PDF or Txt or ANYTHING else...
Daniel N said on Tuesday, 29 September 2009
@SP-User Here is an article that explains what I was talking about: Hope it clears up your confusion. http://technet.microsoft.com/en-us/magazine/2009.06.insidesharepoint.aspx
Glyn Moody said on Tuesday, 29 September 2009
@Scott: thanks for those insights. It was partly that "integrated products" side that I was thinking of. Maybe we need even more openness spread throughout that portfolio....
Jose_X said on Tuesday, 29 September 2009
To all claiming sharepoint has no lockin:
But haven't Microsoft's API always been open? I think that's how Microsoft sells their platforms. And we know how trustworthy history has shown Microsoft to be.
I'm sure as well that there are no interop-breaking bugs and the formats are perfectly open as well. I'm sure of it!!!!!!
As for Google: we don't have the leverage Google has (resources and NDA access). So if the service doesn't convert to open formats (but, let's say, only into their closed cloud services), then the conversions are not that useful to FOSS.
Are Google's file format completely documented (bugs, extensions, and all)?
Competition to Microsoft is better than none, but the gains in this case might not be *that* substantial.
LOVE_MOSS_NOT said on Wednesday, 30 September 2009
Getting rid off Microsoft SharePoint is like asking a stripper for your money back, it's just plain dumb, it won't fly, and you'll look like a fool. Kudos to Google for trying, but let me tell ya, GOOGLE will fail at it. Simple because Microsoft has a psychological impact/effect on people.
New shiny jail said on Wednesday, 30 September 2009
Migrating to Google is more like being transferred from an old and damp prison to a new and shiny one. Google is as much a look in as Microsoft and Google will more likely be a bigger threat to open source than microsoft ever was. Since web services usually is alot cheaper than running your own gear.
Scott Brickey said on Wednesday, 30 September 2009
@ Gov Worker:
SP doesn't like other formats? BS!
1) for files, SP is just a folder with metadata (kinda like what WinFS was supposed to be).
2) for searching/viewing/etc... MS includes their own formats... but it uses the "iFilter" interface... ANY company can write their own code to implement custom code. Of course MS isn't going to write code for every damn file format ever conceived. It's up to the software companies to provide iFilters (which BTW, work with Windows Search!). Adobe and FoxIt already have PDF filters, and I've worked with companies using CAD filters and viewers to search CONTENT WITHIN the files.
Note: it's not always a good idea to store significantly large files (CAD, video) in SP... there are considerations before doing so, though it *can* be done effectively.
ugg said on Friday, 16 October 2009
Ugg boots sales well all over the world, and different countries have various sizes for <A href="http://www.hotterugg.com/ugg-bailey-button-5803-boots-in-brown-for-women-p-1164.html"> Ugg Bailey Button 5803 Boots in Brown for Women</A> . There’re so many size problems we must face when we choose the online purchasing. Now, a beautiful surprise is for all of you! Our <A href="http://www.hotterugg.com/women-5819-ugg-boots-classic-cardy-oatmeal-p-1110.html"> Women 5819 Ugg Boots Classic Cardy Oatmeal</A>is varied into different buy ugg boots according to different needs for size. If you are an American, you can choose the U.S.A. size chart. If you are from Europe, the European shoes size chart is available too. We offer you the opportunity to get the cheap bailey <A href="http://www.hotterugg.com/5815-ugg-women-black-boots-classic-tall-p-1043.html"> 5815 Ugg Women Black Boots Classic Tall</A> at lower prices.