So, I’m currently looking to justify an open-source development model for good chunks of our codebase at our startup (in addition to a more flexible IP policy, but that’s only somewhat related).
I’m curious how others have justified this from a business perspective.
Current arguments for:
- Having open-source helps developers' careers if they decide to move on (they can talk about what they did)
- Open-source helps those building on your company’s product (because they can file better bug reports)
- Open-source helps everyone by reducing the number of wheels that need to be reinvented
- Open-source is the “Right Thing To Do” if you heavily use other open-source projects in your product.
- Having an open-source policy helps attracts higher quality developers
- Having open-source increases the chances of being acquihired
- Having open-source may change the way the market behaves about a new category of product and encourage adoption
- Having open-source encourages customers who may be scared of proprietary/black-box solutions
Current arguments against:
- Older, larger market players may take advantage of open-source to put us out of business
- Newer players in the market may get a jump-start on the tech problems given our open-source
Neutral observations:
- If we’re making 3rd-party integration easy and documenting everything, it’s almost open-source anyways (can always just clone the HTTP APIs and so forth, and build from that spec)
- Heavy market regulation and compliance requirements discourage free-for-all development
~
I’d love feedback, especially picking apart the pros.
If you’ve ever actually seen any of the cons happen, I’d also love to hear about it.
I can’t help but notice that Datastax, Red Hat, Docker, Canonical, and many other vendors don’t seem to have any problems publishing all their source and still keeping a profit based off of services and the hard business stuff.
I’d look at open sourcing small pieces of technology. You don’t want to get a hard-and-fast ‘no’ on the entire idea of open source just because you overreached the first time. If you request to open source small parts that aren’t your core business, it’s a lot easier to make the case for.
You should know what your decisionmakers respond to. I’m not sure how many of those pros make sense from a business perspective.
Be proactive in handling the release, including sending packages, drumming up interest via blogs/Twitter, and managing the release. Document what happens, whether it be issues filed, PRs, or publicity. Stockpile these metrics; their real use is to make the business case for OSS stronger as time goes on. Repeat this cycle periodically.
Speaking for myself, and not on the behalf of my employer:
I note that some of your pro’s are dependent on not just having published source, but on having a Sucessful Open Source Project, which differ greatly in the amount of effort you need to invest.
If you just do your development out in the open, and license your code with an open license, and nothing else, you’ll get e.g. downstream users being able to investigate issues on their own and file great reports or send patches (this is great), but you won’t likely reduce wheel reinvention or change the way the market behaves.
To get real momentum behind an open source project, you need to have accessible communication, and hire/assign people with time and ability to help newbies, review proposed changes and patches, and as things get bigger, even handle politics of governance.
And a lot of that is per-project overhead, meaning that if you release the source to a dozen microservices or parsing libraries or testing frameworks, be prepared to have a dozen new communities that require tending to be of much value, and may result in bad publicity for your company if you stop investing in that tending.
That said, if you’re honest up front about the amount of investment the company will be putting in, most reasonable people won’t be mad if there are no e.g. OpenAngersockFrameworkCon meetings with free Jamba Juice.
Also, as far as ‘Cons’ - I am a little too close to this to offer comment, but you might look at OpenStack to see examples of a community project that was quickly adopted by many competing companies…
I think these are similar concerns to a lot of startups that stay in “stealth” mode for the fear that their idea is so precious and unique that if only someone finds out about it, their business will be ruined. In reality, you will probably have a lot more unique aspects to your business that won’t be code like the people involved, marketing, timing, financial backing, etc. that will not be easily reproducible.
On the other hand, if you don’t have any of those unique components and what you are doing is so basic that anyone could take your technology and quickly make a new company doing the same thing, then your business plan is probably not very sound to begin with. You will be undercut and put out of business whether you open sourced your product or not, but it will be by a small, nimble competitor.
“Older, larger market players” do not move quickly, and will not be able to steal your thunder. What will most likely happen is that an older, larger market player just acquires your company because it’s easier than integrating all of your open source technology. Why? Because they get all those extra components that made your business unique, like your staff and experience.
That’s rather my reasoning–the position I’m fighting against though is “But then they’ve got market-share and our spiffy software”.
The market in question has a few huge entrenched players, and the barriers to entry are quite large (yay healthcare). I don’t think it’s a big threat, but if anyone has examples or stories (either way!) I’d appreciate them.
The biggest rip offs I can think of are people compiling and selling open source software that they didn’t write on Android and iOS with or without a minor branding change. Things like VLC for example. Even if you ported it yourself to Android or iOS you should probably be committing it back into the original project rather than making money off it.
That’s rather my reasoning–the position I’m fighting against though is “But then they’ve got market-share and our spiffy software”.
My counter to that is usually, “And when has that ever mattered?” If they’ve been in the industry long, they should know that deals get done on who you know and (sometimes) price. Ever look at the quality of the software that integration mills like IBM and Oracle churn out? It’s atrocious.
I recently watched this talk on businesses open sourcing code; it’s the voice of experience with some food for thought. (There are big chunks I disagree with, but none that seem germane.)
I’m more concerned by your offhand comment about IP policy.
Remember: you can change your organization or you can change your organization.
So, that’s something I’m working on, right? Changing the organization , so I don’t have to change my organization. :)
Basically, the IP policy as written is “Anything you do while you are employed here belongs to us, unless you clear that it isn’t”.
Now, they’re reasonable folks, and I don’t doubt that that will be the case–but my gut reaction is that of outrage. A broad reading suggests that any work I do in a creative capacity outside of work is subject to this, and that I’ll always have to check.
I’d much rather work with them to define some ground rules that I can point to and save them needless conversations and me needless indignation and stress.
I’m also concerned that that sort of outlook is going to limit who we can hire, because it seems to represent an attitude towards employees that I think the current zeitgeist no longer supports.
I’d love to be set straight on this, mind you.
Basically, the IP policy as written is “Anything you do while you are employed here belongs to us, unless you clear that it isn’t”.
The best time to do something about this is before you’re hired. I’ve frequently crossed out and initialed portions of employment agreements, and most employers don’t even look at them. Those that do have yet to make it a deal-breaker.
However, I’m in the rare/enviable position that I can make these things deal-breakers on my end. I recognize that many people cannot.
Do they pay you for 24 hours of work per day? Is the only creative thing you do creating <insert company product here> in your spare time? Should you bring your rubbish in from home? That is created. Should you bring in your child’s drawings? You probably had some influence there.
I hate broad guidelines like that. My work just has something like “If you are creating audio software then you should tell us about”. Restricted and friendly.
Making money with open source is very difficult, but not impossible. It’s so much simpler just to sell something.
My current thinking is that the best strategy in many cases is to have the “top of the pyramid” be closed. This is the part of your code that makes you money. The infrastructure that it’s based on like Linux and Ruby or Erlang or whatever is open source. You can probably open source some of the infrastructure bits in the middle without really giving anything away. See how that goes, and then move from there as needs be. This is what companies like Google and Facebook do, to varying degrees.
You should definitely have an open source policy because you are doubtless using it already, and some stuff makes complete and total sense to open source.
So, you’re repeating some of the age-old slogans of the original open source movement as espoused by esr, Bruce Perens et al in 1998 when the word “open source” was first coined. With enough eyeballs, all bugs are shallow; release early, release often; scratch an itch, etc. These slogans are sometimes true, and sometimes they are not.
I would like you to think about this in a completely different way: make your software free out of respect for your users' freedom. Freeing your software is just the right thing to do. Don’t lock up your users. Don’t tell them what they can install and how. Don’t tell them what they can change and what they can’t. Don’t attempt to control their computers without their knowledge and/or consent.
And how are you going to make it free and still sell it? A simple way is to actually not give it away to your users without making them pay. There’s nothing wrong with selling free software. If you are afraid of people redistributing your free software, consider the possibility that piracy doesn’t really cut too deeply into video game and movie sales. Why would it be any different for free software?
Another thing you can do is sell (A)GPL exceptions. If your software is hosted, you could charge money for the hosted solution, offer the source, and charge money for AGPL exceptions. That’s how gitorious managed to grow and got bought.
You’re preaching to the choir.
Unfortunately, that sort of profession has already gotten me branded as “fundalmentalist” here. So, baby steps.
Then suggest to whoever’s in charge that they sell exceptions or don’t actually give the software away for anything, just to give it freely.