There are plenty of successful enterprise software providers and there always will be. It really depends on the expertise of the founding team. The product just has to make sense. Some companies stop at the point when the purchase decision make likes the product and stops innovating (or they call move towards scaling, i.e. devote all resources to sales), and that's when they lose their edge.
That's true, but Jaime's point it that it's _spectacularly_ unlikely to get written as "open source".
How many times have you heard people with big plans to "re-implement Microsoft exchange as an open source project"? I think someone I know somehow ends up involved with one of these plans every couple of years, and that's held constant for at least 10 or 12 years, with universally half-arsed execution. They all end up building the bit Jamie proposes (easily sharable group calendars with email/IM/website integration), but _nobody_ ever implements the "Managers" half of what Exchange does, because nobody writing open source software has that itch to scratch.
It's not 100% cast iron guaranteed, but the observation that "enterprise software" gets written by people on salaries in cubicles, and "open source software" gets written by people who don't have to wear suits to work - is so overwhelmingly often correct that we can use any of the very few counterexamples as "the exceptions that prove the rule".
Note too, that "founding teams" are not "typical open source developers", I think a small startup with a great plan and some enthusiastic early-adopter corporate customers is most probably who'll take down the MS Exchange market monopoly... (If they can crack the market before Google does)
I think you also missed the point of the message. It's more that, if what you want to write (given the state of the world at the time) was some software to help people organise their lives, then you have to hit it from a social angle.
People don't want to use Excel and Sharepoint and Outlook, we only do it because we have to. No one would use a piece of non-work software if the use case was 'Create a schedule of events you plan to attend.'
but make the use cases: "Track what your friends are doing." "Meet new people." "Let people know what you're up to."
You are aiming for the things that people might want from the software.
