This summer, after eight years of almost exclusive experience as a SharePoint developer, I branched out and began my first Sitecore project.
After spending virtually my entire career up until now focused on enterprise applications in SharePoint, I felt comfortable with the platform and was able to articulate its strengths and weaknesses, and could recommend solutions based on those. I had gained a deep understanding of many dimensions of the platform, and was confident I could find an elegant, scalable, maintainable solution to just about any problem that came my way.
Moving to Sitecore made me feel like a novice beginner all over again, as every straightforward task and routine configuration issue was an exercise in humility. Nonetheless, thanks to the help of some great colleagues and lots of Googling, I began to build up to a level resembling basic competence. What follows is a quick list of comparisons of the two platforms, based on my vast experience in one and my initial tentative dabblings in the other.
The Out-of-the-Box experience
With SharePoint you get a usable experience right out of the box. You can install the thing and immediately turn it over to your users, who can then start becoming productive right away. They get an information architecture, a full set of security tools, pages, web parts, navigation, and search. You can, and in fact many organizations do, leave it at that and use the OOB SharePoint experience to facilitate productive collaboration.
With Sitecore, on the other hand, you get pretty much nothing out of the box. It's up to you to build out your pages, styling, integrations, navigation, from the ground up. All this amounts to an incredible amount of work just to get to the point that SharePoint gives you from the start.
In other words, with SharePoint, you build your customizations atop the platform, and with Sitecore, the platform sits atop your customizations.
The Installation Experience
For both platforms, the barrier of entry is quite high, starting with installation and even extends to acquiring the installation bits.
With SharePoint, you can obtain the install media via an MSDN subscription, or, if you do not have one, evaluation keys are available, which give you the full functionality in a time-bombed installation, which will stop working after a set number of days. This is actually a good thing because installing SharePoint is really hard, and you'll get lots of practice this way. Besides the daunting hardware requirements - 64-bit server OS, 8-16 GB of RAM - you need a SQL Server and ideally an Active Directory domain you control so you can create users. This can all live on one server, but even so, a SharePoint installation, even for a developer instance, is time consuming, error-prone, and will basically take over your machine, putting great gobs of data on your file system and installing a myriad of services which will choke your system resources.
Office 365, SharePoint's cloud-hosted variant, simplifies this quite a bit, and by forsaking the benefits of server-side functionality, you can have your SharePoint in the cloud quite easily. In recent years Microsoft has moved to become more accessible and more open, and frankly SharePoint is easier to come by than it has in the past.
Sitecore has far fewer moving parts. It also requires a SQL Server, and a MongoDB instance, but other than that its installation is limited to the target site's virtual directory. The challenge with Sitecore is obtaining it in the first place. You can't do anything in Sitecore without a license, and unless you work for a company that does business with Sitecore, you're probably going to be out of luck.
SharePoint has thousands of bloggers, Yammer networks, a Stack Exchange site, and a well-populated documentation via TechNet and MSDN. Despite the frantic pace of its recent development trends, there seems to be lots of relevant information available for pretty much any common task you might encounter in SharePoint: tutorials, videos, sample projects. The challenge with SharePoint is that it's huge and complex and has a bewildering array of farm configurations, authentication schemes, and general corporate wonkiness. Because of this, solutions are rarely one-size-fits-all, and implementation always seems to involve a lot of sweat and tears.
Sitecore does have a community, but it doesn't seem to be anywhere near the size of the SharePoint community. Official documentation is mind-bogglingly sparse, and blog content often seems to assume expert level experience of the reader to comprehend the concepts discussed. One thing Sitecore has in its favor is a much narrower focus - websites, and only websites. The typical tasks you might encounter in Sitecore are pretty much the same from project to project (with exceptions of course) and have well-defined implementation procedures. For example, the pipeline model, the source of so much anguish for me when I was trying to learn it, is actually quite simple and elegant.
To Code or Not to Code
With SharePoint, any experienced consultant will tell you that the best solution usually is the one that does not involve deploying code to the server. Custom code introduces risk into the complex architecture of SharePoint. Poorly-written custom code (and SharePoint seems to have more than its fair share of this) can bog down servers, causing errors and performance issues. In fact, this was one of the driving forces compelling Microsoft to encourage customers to migrate to the cloud. From Microsoft's perspective, bad code increases support overhead and causes customers to think poorly of the product, even when their own bad code is the source of their misery.
With Sitecore, since there is no out-of-the-box experience to speak of, everything must be written from scratch, so literally EVERYTHING IS CODE. This is both a good thing and a bad thing. As a developer, of course I love writing code, and I've really enjoyed all the problems I've gotten to write code to solve. The MVC pattern is another aspect of Sitecore coding that SharePoint devs don't often get to experience, being tied to the Web Forms model for the few opportunities they get to write code-based solutions. The whole configuration patch model is really impressive, and I've had a lot of fun learning how to hook up classes to do things like respond to events or create custom search indexes.
Debugging is also much easier in Sitecore. With SharePoint you never really know which process to attach to. Event receivers are especially troublesome since they run in different processes depending on how they're configured. SharePoint also typically has multiple instances of W3WP running, so if you were attaching to that you would just attach to all of them and hope for the best. With Sitecore, as near as I can tell, everything runs in a single instance of W3WP, and your breakpoints pretty much always hit the first time.
Internal vs External applications
One of the main differences I've encountered in Sitecore is the additional implications resulting from a public facing site. SharePoint projects are mainly, but not always, internal organizational applications, not exposed to the general public, while Sitecore is really built with the public-facing element in mind. This brings up a lot of new considerations, like search engine optimization, accessibility, mobile compatibility, and the pixel-perfect expectations around the visual designs. None of these considerations are specific to Sitecore, but it's just a dimension of the world of public facing web sites.
With internal applications, the requirements are completely different but just as challenging. In this situation you often have lots of different user roles with very complex security requirements built around them. Not surprisingly, SharePoint has the capability to handle these situations, and often understanding the requirements is more difficult than implementing the solution.