Fireside Chat with Paul Graham [video](youtube.com) |
Fireside Chat with Paul Graham [video](youtube.com) |
I think his comments about open source are interesting and how he's never seen anybody open source too much. I humbly disagree, I've definitely seen a few startups get nowhere because they ended up open sourcing their entire product, meaning nobody needed to pay them for anything.
There needs to be a strategy for open sourcing your code...for example if dropbox open sourced their client, they'd still own the relationship to their storage back-end and act as the broker for that data. Their client isn't really worth anything anyways...so it doesn't really matter.
But let's say Microsoft open sourced Office and Windows. Okay, now where do they make their money? They're pretty much just left with services work, and services and support often only exist if the software has problems. Anybody else can then come along and code away their services business by fixing bugs, making better interfaces etc.
Open sourcing needs to have a valid business strategy and it can't just be putting your company's investment up on github because that feels good.
Did you just casually imply Office and Windows don't have problems?
Fun fact: open source support isn't about fixing problems, it's about having someone to contractually blame in case of any problems, not because there are problems. It's more CYA and less TBD.
Also see the MonogDB model — release an open source platform full of bugs and data loss edge cases, target people who don't really know what they're doing so they build prototypes and platforms on top of it, then tell companies they have to pay you if they want any help (and they will need help since the platform is fundamentally flawed in the first place).
Anybody else can then come along
Technically, yes. But has that ever happened? If you open source your 5 million line code base, you still have the expertise, not some outsider.
There's also the reverse problem of open source platforms with no owner (e.g. the ecosystem of ever-growing, zero-authority hadoop vomit).
Open sourcing needs to have a valid business strategy
The valid business strategy is nobody will trust you if you aren't open source these days. The age of vendor-vanish = product-vanish is quickly going away. Companies (as buyers) prefer widely used and open source solutions in favor of closed source voodoo that works "just because we say so" with bad documentation and a tiny userbase.
i disagree. there are many big saas businesses out there and few open source anything.
No, I think you misread or I wasn't clear. Microsoft (and other companies) support service contracts exist purely because of inadequacies in the software. Microsoft wins twice because they sell the software and sell/certify the service organizations.
> Technically, yes. But has that ever happened? If you open source your 5 million line code base, you still have the expertise, not some outsider.
Yes. Why do you think your employees will stay with your company forever?
All a competitor has to do is put out a job req "looking for expert in foo, will pay top $$$" and hire away your expert staff. This does happen and it often happens because purchasing organizations prefer to "separate interests" between vendors and service companies hoping that it forces vendors to build better software that require fewer services. This creates a market for service competitors, and if they're willing to make smaller margins, can pay your people, the people you have in your company doing service work more.
For example, how many people who don't work for Red Hat offer Red Hat support services?
> The valid business strategy is nobody will trust you if you aren't open source these days.
I don't really disagree. Which is why you need to have a strategy that lets you check the "is open source" box with a buyer, while still protecting your business advantage.
See: https://www.quora.com/Many-articles-about-Drew-Houston-say-t... and http://allthingsd.com/20120815/inside-dropboxs-reverse-engin...
Also, doesn't hacking into the OS void the warranty?
Their customers hired them to build out systems that would provide in-house clouds and their tooling helped make HDFS deployment, management and integration a bit easier.
They decided to open source all of their software at some point which meant their model went from:
- Provide tools to make deploying HDFS better, this was their secret sauce
- Provide services to setup/manage all of this
to
- Provide services to setup/manage all of this
Since everything else in their stack was open-source also, their secret sauce consisted of just being a group of engineers, which isn't much of a secret sauce, except they thought it was because "our guys know the ecosystem and tooling we developed" and so charged more for those service engagements.
Their customers realized this, hired cheaper groups of engineers (some of who included previous employees) who then worked with the now free and open sourced tools that "somebody" else had now spent VC money building instead of them.
Inside of a year or so they turned from a successful and growing concern into a VC investment black-hole and closed up shop.
The tooling and many-man-years of effort that went into developing it all was what the business was about and they simply opened it all up to the world, who then just downloaded it and replaced them.
Definitely the kind of guy you could just talk to for hours.
He's been incredibly lucky to be a smart person who managed to make his seed money, and then use it very wisely to turn it into what I guess is now many times what he invested.
It is a shame he has become so busy lately that he can't interact as easily with the "common man" any more. I emailed him not long ago and got no reply. I guess that happens when you have hundreds or thousands of emails in your inbox every day (a problem he has listed often as one he'd like to see solved by a startup).
http://www.evanmiller.org/the-other-money-problem.html
It's scary how many of pg's early startup article titles can be rephrased as "Top 10 secrets VCs don't want you to know!"
Establishing brands/personalities is easier when you are sharing elite wisdom with unwashed masses. It makes the reader feel special and in some ways indebted to you (even if that wasn't the intended effect in the first place).
The Apple App Store approval process is like that one random weak spot on the Death Star. The only question is what replaces it?
If there's a Death Star-level weakness to the App Store, IMHO it's the app discovery process. It consistently rewards the loudest marketers rather than the best developers.
That's just not true. Android and desktop OSX are counter-examples. It is security measures like sandboxing of apps that prevent mobile devices from needing anti-virus software.
On desktop Windows, programs used to have unfettered access to the filesystem, including Windows DLLs that were major parts of the OS. Looking back, it actually seems incredible that it wasn't more of a disaster than it was.
He's also amazing and incredible and handsome and witty and strong and I love him oh so much.
I was 100% on the opposite side of this debate when the iOS SDK first became available. (This was what I had to say about their limitations at the time, if it lends me any street cred: https://www.youtube.com/watch?v=sVkqbycvuKw ).
But at this point the restrictions I objected to have mostly been lifted, to the point where they don't interfere with the vast majority of developers who aren't looking to do something slimy. It's very nice to be able to download and install apps without having to wonder what the developer's real agenda is.
Oh, I've no idea. I'd only go to RedHat for "official" RedHat support?
Another intersecting approach is something like Postgres or MySQL. The ownership of the code is irrelevant at this point and we just have independent consultancies (or integrators) providing expert-level services. But, that's almost a complete inversion of the original premise here of open sourcing your own product while retaining product control + revenue from control of said product. (which sounds like what you're afraid of most general "we open sourced our product" situations devolving into.)
In general, I've seen little interest from random Internet companies in providing support for private open sourced software. Nobody wants to spend months/years understanding your software to compete against your knowledge/expertise (unless you get really successful, but that's a whole other game).
Let's just say, it's pretty big.
Bonus, you don't need to hire an outside firm to administer your Red Hat servers if you just hire somebody with "can administer Red Hat" on a job req.
Here's a short list just to fill out your curiosity (the real one is likely much longer):
http://www.linuxit.com/linux-support-services/
http://www.dcvast.com/software_support_services/redhat_linux...
http://h17007.www1.hp.com/us/en/enterprise/servers/supportma...
and so on.
Red Hat as a company more or less exists these days on name brand. In fact, their EBITD margin is negative despite their stock price riding high.
It is interesting how some software is more amenable to being "business open source" than others.
If your software is touching online, realtime, and mission-critical data, that's a good fit for open source + support / add-ons. You can sell add-ons and ease of use and peace of mind. Some databases have been good open source companies, some have failed, and some are just chugging along not being successes or failures (definitely counts as a VC failure though if you're not a breakthrough success).
If your software is more off-line, or one-time use, or "nice to have" (e.g. a great text editor or a great file upload utility or... sysadmin HDFS deployment helpers) and you currently charge $100/seat for your magic sauce, that seems to be an awful fit for open source. Everybody would use it for free and never consider buying anything from you since it's not "real time mission critical."
Open source is preferred to maintain strong data portability, avoid vendor lock-in, avoid vendor future price increase/licensing shenanigans, and also to get a stronger pool of employees since many may likely have used common popular OSS platforms elsewhere too (less re-training needed in many cases for new hires).
Neither can I.