I wonder what drives people using Microsoft and then using more from this company.
We didn’t knew it better, back then. We knew it better, now. But migrating is work. So we prefer to suffer! And harm others! This Linux and BSD people are so annoying with their desire for compatibility. They shall suffer, too! And when we buy everything from a Monopoly, we don’t need to think.
Somehow. Part of the game is that you’ve always an excuse with Microsoft. You cannot made responsible? There is this quote about IBM:
Nobody Ever Got Fired for Buying IBM.
But I cannot remember stories about suffering from IBM forever.
From what I've seen in my industry? To pass all the liability to Microsoft.
"If something happens, we used enterprise grade industry standard software. We did our due diligence."
This outlook is basically why we can't innovate anymore.
I had to recently sit through a meeting where our CTO quoted all the "blogs" he's been reading as a way to slap down my suggestion for an in-house project.
It's why school boards don't do anything useful, among many many other things in our society. It's an endemic disease.
Most of the time it's extremely exaggerated, but it's trotted out and used as a CYA excuse almost immediately by most in the executive/managerial class. Both due to outright laziness and incompetence, and also as just a... why take any personal risk whatsoever making actual decisions with any impact if I can keep my cushy job and career rolling by being as milquetoast as possible.
Never mind you get the big bucks to make such important and controversial decisions at great personal (career) risk when some inevitably go wrong. Everyone forgot that part. Such roles should be hard, difficult, and risky.
They're using Microsoft because all of the alternatives have the same issues.
FOSS isn't magically immune to vulnerabilities.
It doesn't help that the FOSS community generally prefers the C programming language over more modern and safer alternatives as a cultural thing. The result is just as many vulnerabilities, if not more, per line of code or per feature. Keep in mind that SharePoint is an enormous product with a 3.6 GB ISO image used to install it. If you think anyone is able to develop that volume of server code and have zero vulnerabilities... I have a bridge to sell you.
Valid point about the image size. A possible sign for bloat? Bloat is danger.
Second:
C, C++ or Rust are our tools. Everyone prefers another for technical and personal reasons. A religious believe in salvation by the next programming language is not helpful and causing harm. I hope sanitizers for C/C++ improve further - which improved safety a lot. For C++28 or C++3x we can hope for further safety improvements. Which we need.
Most bugs are logic errors. SharePoint is - according to my knowledge - implemented in C#. The CVEs mention deserialization of untrusted data, improper limitation of a pathname to a restricted directory ('path traversal'), improper control of generation of code ('code injection') and so on.
I'm rather careful about people requiring another language and claiming it will fix everything. Reliability needs hard work (design, code, review, testing...more review) even with well selected tools. I guess Microsoft does that. And I guess Microsoft works like the rest of the industry, focus on time-to-market and building a monopoly in every area. That's why we see rapid updates in a lot areas and - worse - enforced updates. And why software is known for it's low quality in comparsion to other industries?
Examples:
GNOME opted to use JavaScript in the hype back in 2010:
* JavaScript reduced compatibility compared to C/C++.
* They suffered a lot from memory-leaks. Due to JavaScript.
* The run-time modification seems not to be a big benefit.
* Extra dependencies for JavaScript. More memory usage.
The code matured and it works now rather well. I didn't liked the decision back then. I don't like it now. But I also don't request a rewrite in C, C++, Rust or Python. Without good reasons (plural) it doesn't benefit the project.
Java also suffered. This rewrite of C++ to Java with JRE is a example, why rewrites for the sake of rewrites aren't a solution:
Rust has never been successfully used to develop large-scale software of the size of SharePoint, Exchange, or anything of that order of magnitude: gigabytes of compiled code with the main executable being 10s of megabytes in size.
An observation I've made about Rust is that because it eschews OOP, it tends not to "scale" to large development teams for single applications. It's great for CLI tools, small web apps, etc... but after some scale it runs out of steam.
This is exacerbated by its glacial compile times compared to other languages, even C++, let alone C#.
I just can't imagine something the size of SharePoint being developed entirely in Rust!
Think of an app like SharePoint as "Linux Kernel + Drivers + Userspace tools". There's a few large monolithic executables some tens of megabytes in size for each of the core web apps and services, and then hundreds file format converter plugins, database drivers, etc, etc...
Chromium is similar. It's practically an operating system now, it even has USB drivers! I had to compile Chromium from scratch once, for which I spun up a 120-core cloud VM with 456 GB of memory so that it wouldn't take all day.
With Rust... that would take all week even on that box.
I mean.. people contributing to FOSS generally program in what they know - i.e. I have some time to contribute, I'll spend 10 productive hours in C, because I know what I'm doing, vs. learning Rust only to spend 30 hours and not really getting anything done.
I contributed to a Tcl/Tk library that I was using at work that had a specific issue with some image files, so I fixed it internally, and contributed the fix back to the FOSS project (with permission from work).
People working at Microsoft in the SharePoint team also program in a language/framework they know (and they must be masochists if they're working with ASP.NET WebForms). Knowledge of the language doesn't prevent vulnerabilities.
Genuinely asking - is there a Linux alternative to Sharepoint? I couldn't care less if it was lit on metaphorical fire and dumped into the sea, but a lot of orgs using it extensively.
For collaborative documentation, there’s probably a bunch of alternatives.
But SharePoint is the linchpin for Microsoft 365. Well technically SharePoint and Exchange. You can’t use any Microsoft 365 products without SharePoint.
OneDrive uses SharePoint. Outlook Groups and Teams Channels create Microsoft 365 Groups. Every Microsoft 365 Group creates a SharePoint site. Microsoft Loop uses Microsoft SharePoint Embedded.
SharePoint is now a “file and document management system suitable for use in any application”.
So, if you want an alternative to SharePoint you would need an alternative to any M365 Product, including Outlook and OneDrive.
Fun Fact: Teams messages are actually stored via Exchange Mailboxes.
Google Docs and Libre Office both produce compatible documents. There's really no reason to force one or the other.
It's just conflating needs. Document editing and file storage are two different tasks. It's weird that people want everything integrated. It's not much effort to just drag and drop a file into G-Drive, OneDrive, Dropbox, box.com...
What people want are systems that compose and work well together. That's what MS provides, or at least attempts to provide, with SharePoint. When you start trying to tack on collaborative document editors, workflow management systems, shared storage, and other capabilities from different providers or systems you run into more and more complications (especially because most of these don't offer any kind of standards compliance that lets them be used interchangeably). That's also why G-Suite works as a competitor to MS, it covers at least the more critical integrations that people want to work smoothly without needing to combine multiple maybe compatible things together.
> I've never been able to properly work on a Word document together with a colleague. Not even once
Many millions of others seem to do it all the time without issue. I've done it practically every day for many years now and haven't run into sync issues for a long time.
It's not made to sync if two people are trying to open the file off a NAS, it's made for people editing files stored in OneDrive/SharePoint.
But as both examples show, you need to have your document editing and document storage closely working together for multi-user live editing to work. That's something that so far practically only integrated editors/storage platforms offer.
Which is so funny because it was a pain in the ass on prem to make sharepoint work for that purpose. Silly item restrictions, complaints about database sizes (which stored the files), etc
Sure. Just saying when that first was brought up in 2007+ and I had to admin it and people loved their folders and searching and such wouldn’t work because if the view sizes.
Nextcloud, particularly with the Collabora Office integration for real-time collaborative document editing. It's got some rough edges but I'd say it suits the majority of use cases now. I suggest spinning up a copy of the community edition in a VM to give it a spin, I was pleasantly surprised. There is a lot of money getting poured in right now as entities outside the US are exploring ways to ditch American software.
Sorry, I don’t know the answer to your question, but I can offer some possible insight into why it’s used so much.
We’re on Microsoft 365 and technically fall into the camp of “uses SharePoint”, but only for “shared network folder” usage which OneDrive seamlessly synchronizes should you dislike the web interface. We don’t actively use any other features of it.
Also worth mentioning that realtime collaboration and automatic versioning of Office documents is seamless for files on SharePoint, even if opened on a desktop on a OneDrive synchronized folder.
Files shared over Teams as well as meeting recordings are also stored on SharePoint.
My point is that SharePoint is used a lot but possibly not in the way one might have assumed.
I don’t know if self hosted SharePoint can do all this.
For the file storage/sharing/collaboration part, yeah - there's plenty, and sharepoint arguably sucks even for that.
What trapped a lot of orgs is making use of the whole PowerPlatform around sharepoint. There's a lot of crusty old LoB apps built with MS's no code tools (PowerAutomate, PowerApps) which run on SharePoint as the delivery platform. Some of these even hook into Excel files stored in the various document libraries, etc. There are entire, large business processes being handled by this platform, and so migrating will require actual dev time, which automatically makes it a non-starter for most, unfortunately. Doubly so when you consider that a lot of these "solutions" were built by non-devs, long since gone from the company and no one knows how deep the tentacles go.
> Genuinely asking - is there a Linux alternative to Sharepoint?
Genuinely asking - is there a Microsoft alternative to eBPF, k8s, nginx?
The answer is NO. Alternative to SharePoint is SharePoint. I would argue such project just not needed in general and therefor there is no 'alternative'.
O365 is a poor amalgamation of like 18 different things. Quite frankly I hope there isn't a true "alternative" to it.
The reason orgs use Sharepoint is they are forced to if they use Microsoft. One drive is sharepoint, teams is sharepoint, sharepoint sites is sharepoint, etc...
I'm sure all those things have better alternatives, but Microsoft shoves them down your throat when you license with them.
But it's understandable why an org would prefer that to having to maintain and manage the 18 things, right? It's a hard sell.
I'm not saying that wouldn't be better, but it makes sense why an org would be reluctant. Again, not a fan of Sharepoint myself, but from an org's viewpoint, moving to Linux raises more problems than it solves.
It's understandable, but it doesn't excuse how poorly everything actually works and how confusing it is to use and administrate.
To some extent I think Microsoft is largely in the business of building solutions for problems that don't exist.
Most orgs are probably perfectly fine with a document management system + desktop word application and then a commercial NAS for bulk storage / backups.
As far as I can tell there's two vulnerabilities bundled up here. One is an unauthenticated command injection (!) vulnerability to steal some keys and the other is of course yet another serialization-based RCE in a safe language, mediated by signed cookies (signed with the keys stolen in step 1).
I don't understand how often this design has to blow up in people's faces until they stop doing this and use something dumb and safe instead.
I operate under the assumption that open source projects are compromised by states. If you espouse unpopular ideas or are yourself a state don’t rely on it.
Lets pretend what you are saying is true, which it is not. Who would you want to access your data ? The State or the "underworld". Many countries have laws on how to access your data. The underworld, you may wake up dead.
Granted there are countries that act like a Criminal Org., but if you live there you have more issues than your data.
With proprietary software, it is a much larger chance that backdoors exist than in Open Source. Many of us heard of 1 issue where it was claimed a project had a Gov sponsored BH in it. They did a long audit and found that was false.
Eventually Open Source backdoors will found in Open Systems. Proprietary you are SOL unless you do very expensive and very hard testing. Even then it is doubtful you will find a backdoor.
It is true. Denying trivial truths with the purpose of not giving an inch does not add to one's argument, it weakens it.
Plenty of closed source products will happily backdoor their products on request, without a warrant, if they are confident they will never be found out. That's the point. Not that FOSS source is somehow inviolable to nation-states with virtually infinite resources, many of which sponsor or contribute to the finance of a huge percentage of the development of FOSS themselves.
It's easier to find backdoors in FOSS if you're looking, because you're allowed to look. But somebody has to be looking.
Probably not since there are so many of these breaches people just ignore them.
I miss the old days when a breach involved someone breaking into the computer room and grabbing as many mag tapes as they can carry and run :)