This is another datapoint that generational attitudes towards the value of software have shifted.
In the early days of software, it was an afterthought: what made it possible for IBM and others to sell the more valuable hardware asset.
Microsoft (founded 1975) perceived the economic opportunity attached to volume distribution of user facing machines, and helped usher in an age where the value shifted from the hardware to the software.
Google (1998), by contrast, derived effectively zero revenue from software directly. Instead, they leveraged open source and commodity hardware to control their costs and were able to scale more effectively than existing search alternatives. While they didn't sell software, however, they continued to perceive it as a competitive advantage, and thus a minority of their overall development was shared via public repositories.
For Facebook (2004), Twitter (2006) and GitHub (2008), like Google, software is the means to an end rather than the end itself. Unlike Google, however, most do not behave as if code itself is a competitive advantage. You can argue about what their actual product is - a critical mass of users, the data they generate or both - but you can't build the case that it is primarily the software.
And if the software doesn't represent a competitive advantage, the follow on benefits of releasing it as open source software - whether it's general goodwill, amortizing development costs, greater efficiencies in hiring and recruitment, etc - are believed to outweigh the costs.
Hence Cassandra, FlockDB, Hip Hop, Hive, Jekyll, Resque, Storm, Thrift and so on.
None of these entities open source the entirety of their infrastructure, but it is increasingly common to see open source as the default rather than the exception.
Software has and will continue to have value. But in an increasing number of cases it will not represent a competitive advantage, and therefore assuming the burden of maintaining it internally will become less attractive.
> Instead, they leveraged open source and commodity hardware to control their costs and were able to scale more effectively than existing search alternatives.
I would propose a caveat that Google's initial strength wasn't merely that it scaled better but that it used a search algorithm that produced better results. As Tom Preston-Werner argues, Google jealously guards their PageRank algorithm because it "represents core business value".
Very insightful. Reminds me of a talk I saw Tim O'Reilly give at OSCON back in the day, basically about this same concept. He described it as "moving up the stack", with each successive phase commoditizing the thing beneath it (hardware at the bottom, then software, then services). Here's a link to his writeup of the concept (although it's kind of dry -- I remember the presentation itself having more pictures and being more engaging):
http://tim.oreilly.com/articles/paradigmshift_0504.html
I wonder what's going to sit above "services" in the next phase? Maybe the services will be commoditized because there will be so many of them that do similar things and they all talk to each other via RESTful interfaces... so then the thing that's valuable is whatever sits above that. Identity systems? Yahoo Pipes? I dunno... predicting the future is hard, let's go shopping!
In college I did some App Engine development. At a previous job, we used open source Google Java libraries like Guice and Guava. I recently started at Google and walked in the door largely proficient in using their stack. In my opinion, they did everyone a favour.
They've done good by other companies by providing them with solid libraries. They did right by me -- knowledge of their libraries presumably made me a stronger candidate. Finally, they did right by themselves by reducing the time it took me to get up to speed.
I've generally come to the conclusion that open sourcing tangential software is a good cultural/social practice. Adopted broadly, it represents a gigantic time-savings for our industry, allowing us to collectively push forward to other more interesting problems than writing company-specific ci server/build system/source control system, etc.
One simple rule of business: commoditize your complements.
Apple sells hardware and "gives away" all their media.
Content creators and developers are charged only enough (30% margin) to basically break even managing the system. This adds tremendous value to their hardware since they now have "an ecosystem" and not just some electronic widgets.
Aside: Apple have set prices for music but assumed app developers would always charge for their apps. When huge numbers of developers started giving away apps for free, Apple came out with iAds in an attempt to defray the cost of hosting free apps. They don't do anything for free.
So, the same applies to open source and hiring. Good engineers are hard to find. If you outsource your software and it becomes popular, good engineers will flock to it.
You've now got engineers pre-trained (for free) on an important component of your system and they are dead easy to identify, defraying the cost of recruiting.
Since open source is the commodity in this scenario, giving it away for free is the most prudent way of insuring widespread use and a good supply of engineers.
Edit: another idea is "give away your ideas, sell the system". Open source your non-core ideas to attract attention and sell your complete system. Although many marketers argue the reverse: give away your BEST ideas to prove your worth and build trust then sell them on the whole package.
One of the strongest arguments is modularity. It's definitely true that you prevent your code from rotting and acquiring random dependencies if you think about how you can export it as a useful open source library.
As I and my teammate started working on Candy (http://amiadogroup.github.com/candy) we knew that we want to open-source the project. Therefore we built everything so modular and flexible that even we used the vanilla Candy and wrote just some custom plugins for our own use-case.
The article begins by discussing their choice to open source an integral part of their product. The article ends with an admonition: "Don't open source anything that represents core business value." It seems like Grit certainly represented core business value, yet they open sourced it.
I'm guessing that what they really mean is that you should open source almost everything that represents core business value, but one piece should always be left out. Or, perhaps they're saying that their web interface is the core value they provide, and so they open source everything but that.
I think you're reading "core business value" too broadly. Github might not exist without Grit, but the crucial test is that Grit might exist without Github. Grit itself --- the ability to interface with git --- it's something specific to the functionality of Github, it has broader applications. This isn't something true of Github, and neither is it true of their Jobs site, since it has (apparently, never used it) direct and deep integration with Github.
That's less "core" than what Tom seems to mean. By looking at the examples he provides, the essential distinction seems to be this:
If somebody found the code, would cloning your business be the obvious thing to do with it?
This isn't true of Grit. It is true of the core GitHub app, and it is true of the GitHub Jobs app.
Interacting with Git from Ruby is not the core business value of GitHub. It's just something GitHub does in the process of providing its real core business value, which is the awesome interface and collaboration features they've built on top of Git.
Reading on, "Open sourcing it would mean thousands of people worldwide could use it to build interesting Git tools, creating an even more vibrant Git ecosystem."
Awesome Git bindings to Ruby are critical to the functionality of Github, but a vibrant Git ecosystem is essential to its success. Business value trumps technical implementation.
In fact, Tom also mentions the libgit2 library that Github is working on, and may even replace some of what they use Grit for today.
Another point: Zurb recently open-sourced their CSS/JS framework that they use to build all their client sites/apps with. They have spent years making it awesome. It's a major part of the material goods that they hand over at the delivery of a project. After it being opened up on Gitub, they've seen lots of great feedback, bug fixes and enhancements. I'd also bet they've seen an increase in new clients. What they wrote is awesome and now they are known to many more potential customers as being the people who know what they are doing.
If your product relies on the network effect for its success (as GitHub does) and you've already established yourself, it doesn't seem to me that open sourcing your software would be a bad idea. See Reddit as another example.
There are two schools of thought, in marketing, on giving away parts of your business, your ideas etc:
Give away your non-core ideas to attract people/resources/interest and then sell your complete system.
Give away your core ideas to "prove your worth" and build trust/authority/recognition and sell your complete system.
The second version is more powerful but it takes a leap of faith. Others could poach your work and use it against you but truly viable competitors are rare and people are lazy, the odds of this happening are often slim.
Another way is to make one piece of the open-sourced version run slower than an equivalent optimized closed-source version that does the same thing in the proprietary distribution of the same product. That way the business can make the claim "completely open sourced", knowing if anyone forks their product it will run slower.
The primary advantage they have over competitors is a trusted brand name. This name has been built, in part, by engaging and contributing to the open source community.
If GitHub were to open source _all_ of their software, some copycat sites may appear. These sites would not have a trusted name, thousands of well known open source projects backing them up and the expertise to properly run an instance of GitHub. As long as GitHub doesn't try charging users too much to use their service, there is no reason for people to use competitors to save a few dollars a month (reliability is far more important than a few dollars here and there).
Some open source projects may decide to operate their own infrastructure. However, this is highly unlikely because GitHub _as a service_ is much easier and more reliable than an independently managed instance. If GitHub can retain the open source community, they become "the hub" that everyone wants to be part of. As long as GitHub is known to support open source in a meaningful way, given the resources available, I'm sure they'd benefit from hundreds of open source projects improving upon and patching GitHub code.
I think they could quite readily open source _all_ of their software.
makerbot has the distinct advantage of having open-sourced a (largely) physical product. For me at least, paying them for the bits and pieces to put their printer together would be an order of magnitude less effort than compiling and installing some software downloaded from the internet. They still offer a valuable service in manufacturing parts, and hence don't have to just sell support to make a living.
The MIT license has no patent release. I think this alone should eliminate it for all but the most basic of projects. Yet the author doesn't even seem to realize this.
Another company that i think does very well in open sourcing is Kitware. All their projects are open-sourced; and I know from personal experience that these are very good pieces of code that they just give out for free. Apparently, their strategy is that their flagship product (vtk) is so big that there is more benefit for a small company to have lots of other people looking at the code, using it and sometimes improving and committing back the changes; also, that there are just too many cool things that one can do with it, leaving Kitware enough opportunities to create customized products for a fee(of course, they also provide paid support services as well). For me personally, it meant that my monetary constraints (grad student here) were not a hurdle in my research.
"the GPL is too restrictive and dogmatic to be usable in many cases"
Does anyone else see the total irony in this? Considering that both Ruby and Git (two of the core technologies GitHub runs on) are both GPL. People can use whatever OSS license they want, I certainly have no gripe with him using the MIT license, but I could do without the dogma.
I have a question for the OP... Why the MIT licence, and not putting your code in the public domain? Is it the liability issues, or the attribution, or something else?
I mainly pose this question because I am choosing a licence for my projects, either the MIT/Apache licence, or public domain.
My understanding is that there are more legal gray areas with public domain than there are with even very permissive licenses (MIT, new-BSD, etc). I vaguely recall something about potential issues with public domain and other license incompatibilities, but I don't recall the specifics (and am certainly not a lawyer), so that probably isn't a useful datapoint.
Apache license has patent clauses that make it quite different than the new-BSD/MIT-style licenses.
In general, since I don't know a huge amount of the legal issues involved in public domain and national jurisdictions in regard to such, I simply err on the side of caution and choose MIT license for software I want to release as freely as possible. Others use it so it likely has more legal precedent and courtroom experience around it (should it ever come to that), and I like the notice of warranty disclaim (a bit of cya).
There is forced attribution and the fact that in some countries putting work under the public domain doesn't mean you give up a lot of rights to it. You need to have a specifically liberal licence in order to do that.
What is the One True License?
I prefer the MIT license and almost everything we open source at GitHub carries this license. I love this license for several reasons:
It's short. Anyone can read this license and understand exactly what it means without wasting a bunch of money consulting high-octane lawyers.
Enough protection is offered to be relatively sure you won't sue me if something goes wrong when you use my code.
Everyone understands the legal implications of the MIT license. Weird licenses like the WTFPL and the Beer license pretend to be the "ultimate in free licenses" but utterly fail at this goal. These fringe licenses are too vague and unenforceable to be acceptable for use in some companies. On the other side, the GPL is too restrictive and dogmatic to be usable in many cases. I want everyone to benefit from my code. Everyone. That's what Open should mean, and that's what Free should mean.
I agree with everything but the "core business" stuff and the MIT License.
The same principles apply to your core business - independent of what it is (not only GitHub).
By opensourcing all of your business, you will gain all the synergy you mentioned (i.e. libgit2) within your core.
Your competitors will benefit from it, but they won't be a challenge to you as long as they don't have the passion and insights from your team. If they can find a way to do better than you with that knowledge (expressed as software), then your position in the market is based on imperfect information (and therefore, monopolization power).
Although you may have everything to start a DVCS frontend, it is not an easy task which doesn't rely only on software: you need the ability to understand the infrastructure needed for the problem and maintain it at a reasonable speed - armies of proficient developers extending and fixing bugs, armies of sysdamins, coordinate them, decide adequate directions, etc.
Besides that, you need passion about what to do in order to keep kicking asses. Without it, it is not sustainable in the long run. Think about Launchpad, I think they add extra functionality to bzr than GitHub to git, yet people still sticks to GitHub. Why?
Also if you opensource your "core", people will need also customizations, so your competitors can become your clients where you provide developing to them - they may target other niche that you can't or your are not interesting.
This is where the license comes in: the best way of achieving this is by using AGPL3.
With AGPL3, you make sure that everything you gave it won't be restricted to others - as you haven't restricted anyone by opensourcing it.
You are not restricting others' freedoms, they can do whatever they want with the software. When someone closes the source, it's restricting others freedom, not his. What you can't do with AGPL is taking away others' freedom and right to know what they are using.
If someone improves it, then it will come back to you, and you will be able to improve from others as they improved from you.
The MIT license is good, but it doesn't close the loop and may have leaks, :D heheh!
>then your position in the market is based on imperfect information (and therefore, monopolization power).
Good! Who wants their living standard to be dependent on a never ending rat race of constantly out-innovating competitors? Especially when there are really big players out there that can throw huge resources into taking your market share.
> they can do whatever they want with the software
What if they want to build something on top of it that is not open source? They cannot and that is a restriction. It is the definition of a restriction.
> When someone closes the source, it's restricting others freedom, not his.
How so? No one is restricted if somebody makes a private fork of a codebase.
That's like saying that if I don't go to the bar down the street tonight the people there are restricted from having fun.
I don't necessarily agree with the author that "it is the right thing to do". He may believe we are morally obligated to give back to the community, and that is his belief, and that's fine, but I do not share his belief.
I'll contribute back to the community happily. I do so because I want to. But I do not feel that I am morally obligated to do so. I'm sorry, I simply don't.
The author makes the point that one should give back, for example, simply because one "used the internet". It is one thing to say that you should open source your code and give it back to the community if it is derived in some way from another open source project. It is quite another to say that just because you use open source, you are now morally obligated to give back to the community.
All of you out there using an Android phone - do you feel morally obligated to open source your work simply because you use a phone that is built predominantly on open source code?
Another company that came to mind while reading the article is Shopify. While their core business is eCommerce, they have open sourced some of the major components of their system while still keeping the app that glues them together proprietary.
Some notable mentions:
Active Merchant (payment processing library)
Active Fulfillment (external fulfillment for Amazon/Shipwire/Webgistix)
Active Shipping (shipping carrier integration)
Delayed Job (job queue)
Obviously there is a lot more work that goes into making a product as polished as Shopify, but they have released a large amount of core domain knowledge for other people to use and improve upon. While someone might be able to come along and use the same components to create a competitor, they still win in the end by having more people contribute.
I've started open sourcing more things lately, mostly in the realm of things that solve a problem I have that might solve someone else's problem. Sometimes I build tech for tech's sake that improves my software or apps, but it isn't a product in itself. Frameworks, libraries, templates, and tools all tend to fall into this category I think and github is a great example is open sourcing these things.
You shouldn't open source your product itself unless you want to be a service company. I personally don't care to become a service company, so I keep the "product" and the data behind it closed, but the frameworks, tools, etc. can and should when possible be open source.
The product and data in this case is your "core" that the article is advocating to keep close to your chest while outsourcing the non-essential components that would attract interested parties to your work.
The GNU Project has extensive commentary on a variety of open-source licenses. They recommend the Expat or FreeBSD license over the MIT license, because MIT has released code under numerous licenses so the term "MIT license" may be legally ambiguous.
If there's one thing time has proven it is that open source projects (usually) leave a lot to be desired in the UI department. UI is one of those things where a benevolent dictator is a good thing, it gives you consistency and given a talented designer leading the team gives you a far better product.
The typical path for for open source UIs seems to be to try to please everyone, which means making something that isn't great for most people who don't want to spend half a day customizing their interface.
[+] [-] sogrady|14 years ago|reply
In the early days of software, it was an afterthought: what made it possible for IBM and others to sell the more valuable hardware asset.
Microsoft (founded 1975) perceived the economic opportunity attached to volume distribution of user facing machines, and helped usher in an age where the value shifted from the hardware to the software.
Google (1998), by contrast, derived effectively zero revenue from software directly. Instead, they leveraged open source and commodity hardware to control their costs and were able to scale more effectively than existing search alternatives. While they didn't sell software, however, they continued to perceive it as a competitive advantage, and thus a minority of their overall development was shared via public repositories.
For Facebook (2004), Twitter (2006) and GitHub (2008), like Google, software is the means to an end rather than the end itself. Unlike Google, however, most do not behave as if code itself is a competitive advantage. You can argue about what their actual product is - a critical mass of users, the data they generate or both - but you can't build the case that it is primarily the software.
And if the software doesn't represent a competitive advantage, the follow on benefits of releasing it as open source software - whether it's general goodwill, amortizing development costs, greater efficiencies in hiring and recruitment, etc - are believed to outweigh the costs.
Hence Cassandra, FlockDB, Hip Hop, Hive, Jekyll, Resque, Storm, Thrift and so on.
None of these entities open source the entirety of their infrastructure, but it is increasingly common to see open source as the default rather than the exception.
Software has and will continue to have value. But in an increasing number of cases it will not represent a competitive advantage, and therefore assuming the burden of maintaining it internally will become less attractive.
[+] [-] RyanMcGreal|14 years ago|reply
I would propose a caveat that Google's initial strength wasn't merely that it scaled better but that it used a search algorithm that produced better results. As Tom Preston-Werner argues, Google jealously guards their PageRank algorithm because it "represents core business value".
[+] [-] jordanlev|14 years ago|reply
I wonder what's going to sit above "services" in the next phase? Maybe the services will be commoditized because there will be so many of them that do similar things and they all talk to each other via RESTful interfaces... so then the thing that's valuable is whatever sits above that. Identity systems? Yahoo Pipes? I dunno... predicting the future is hard, let's go shopping!
[+] [-] bhickey|14 years ago|reply
In college I did some App Engine development. At a previous job, we used open source Google Java libraries like Guice and Guava. I recently started at Google and walked in the door largely proficient in using their stack. In my opinion, they did everyone a favour.
They've done good by other companies by providing them with solid libraries. They did right by me -- knowledge of their libraries presumably made me a stronger candidate. Finally, they did right by themselves by reducing the time it took me to get up to speed.
[+] [-] pnathan|14 years ago|reply
+1, GitHub.
[+] [-] alexhawket|14 years ago|reply
Apple sells hardware and "gives away" all their media.
Content creators and developers are charged only enough (30% margin) to basically break even managing the system. This adds tremendous value to their hardware since they now have "an ecosystem" and not just some electronic widgets.
Aside: Apple have set prices for music but assumed app developers would always charge for their apps. When huge numbers of developers started giving away apps for free, Apple came out with iAds in an attempt to defray the cost of hosting free apps. They don't do anything for free.
So, the same applies to open source and hiring. Good engineers are hard to find. If you outsource your software and it becomes popular, good engineers will flock to it.
You've now got engineers pre-trained (for free) on an important component of your system and they are dead easy to identify, defraying the cost of recruiting.
Since open source is the commodity in this scenario, giving it away for free is the most prudent way of insuring widespread use and a good supply of engineers.
Edit: another idea is "give away your ideas, sell the system". Open source your non-core ideas to attract attention and sell your complete system. Although many marketers argue the reverse: give away your BEST ideas to prove your worth and build trust then sell them on the whole package.
[+] [-] chubot|14 years ago|reply
[+] [-] mweibel|14 years ago|reply
As I and my teammate started working on Candy (http://amiadogroup.github.com/candy) we knew that we want to open-source the project. Therefore we built everything so modular and flexible that even we used the vanilla Candy and wrote just some custom plugins for our own use-case.
I think it definitively leads to better code.
[+] [-] baddox|14 years ago|reply
I'm guessing that what they really mean is that you should open source almost everything that represents core business value, but one piece should always be left out. Or, perhaps they're saying that their web interface is the core value they provide, and so they open source everything but that.
[+] [-] pavpanchekha|14 years ago|reply
[+] [-] chc|14 years ago|reply
If somebody found the code, would cloning your business be the obvious thing to do with it?
This isn't true of Grit. It is true of the core GitHub app, and it is true of the GitHub Jobs app.
Interacting with Git from Ruby is not the core business value of GitHub. It's just something GitHub does in the process of providing its real core business value, which is the awesome interface and collaboration features they've built on top of Git.
[+] [-] briandoll|14 years ago|reply
Awesome Git bindings to Ruby are critical to the functionality of Github, but a vibrant Git ecosystem is essential to its success. Business value trumps technical implementation.
In fact, Tom also mentions the libgit2 library that Github is working on, and may even replace some of what they use Grit for today.
Another point: Zurb recently open-sourced their CSS/JS framework that they use to build all their client sites/apps with. They have spent years making it awesome. It's a major part of the material goods that they hand over at the delivery of a project. After it being opened up on Gitub, they've seen lots of great feedback, bug fixes and enhancements. I'd also bet they've seen an increase in new clients. What they wrote is awesome and now they are known to many more potential customers as being the people who know what they are doing.
Business value trumps technical implementation.
[+] [-] GrahamL|14 years ago|reply
[+] [-] alexhawket|14 years ago|reply
Give away your non-core ideas to attract people/resources/interest and then sell your complete system.
Give away your core ideas to "prove your worth" and build trust/authority/recognition and sell your complete system.
The second version is more powerful but it takes a leap of faith. Others could poach your work and use it against you but truly viable competitors are rare and people are lazy, the odds of this happening are often slim.
[+] [-] vorg|14 years ago|reply
Another way is to make one piece of the open-sourced version run slower than an equivalent optimized closed-source version that does the same thing in the proprietary distribution of the same product. That way the business can make the claim "completely open sourced", knowing if anyone forks their product it will run slower.
[+] [-] kiba|14 years ago|reply
The only example I can think of is makerbot industries in which their core technologies are open source.
[+] [-] brandall10|14 years ago|reply
"Ok, then what shouldn't I open source? That's easy. Don't open source anything that represents core business value.
Here are some examples of what we don't open source and why:
Core GitHub Rails app (easier to sell when closed)
The Jobs Sinatra app (specially crafted integration with github.com)"
[+] [-] dhx|14 years ago|reply
The primary advantage they have over competitors is a trusted brand name. This name has been built, in part, by engaging and contributing to the open source community.
If GitHub were to open source _all_ of their software, some copycat sites may appear. These sites would not have a trusted name, thousands of well known open source projects backing them up and the expertise to properly run an instance of GitHub. As long as GitHub doesn't try charging users too much to use their service, there is no reason for people to use competitors to save a few dollars a month (reliability is far more important than a few dollars here and there).
Some open source projects may decide to operate their own infrastructure. However, this is highly unlikely because GitHub _as a service_ is much easier and more reliable than an independently managed instance. If GitHub can retain the open source community, they become "the hub" that everyone wants to be part of. As long as GitHub is known to support open source in a meaningful way, given the resources available, I'm sure they'd benefit from hundreds of open source projects improving upon and patching GitHub code.
I think they could quite readily open source _all_ of their software.
[+] [-] fendrak|14 years ago|reply
[+] [-] SeanLuke|14 years ago|reply
[+] [-] nirvdrum|14 years ago|reply
[+] [-] halostatue|14 years ago|reply
[+] [-] tingletech|14 years ago|reply
[+] [-] pm90|14 years ago|reply
[+] [-] peterbe|14 years ago|reply
[+] [-] trafficlight|14 years ago|reply
[+] [-] cmurtagh|14 years ago|reply
Does anyone else see the total irony in this? Considering that both Ruby and Git (two of the core technologies GitHub runs on) are both GPL. People can use whatever OSS license they want, I certainly have no gripe with him using the MIT license, but I could do without the dogma.
[+] [-] wbkang|14 years ago|reply
[+] [-] tomp|14 years ago|reply
I mainly pose this question because I am choosing a licence for my projects, either the MIT/Apache licence, or public domain.
[+] [-] stock_toaster|14 years ago|reply
Apache license has patent clauses that make it quite different than the new-BSD/MIT-style licenses.
In general, since I don't know a huge amount of the legal issues involved in public domain and national jurisdictions in regard to such, I simply err on the side of caution and choose MIT license for software I want to release as freely as possible. Others use it so it likely has more legal precedent and courtroom experience around it (should it ever come to that), and I like the notice of warranty disclaim (a bit of cya).
[+] [-] true_religion|14 years ago|reply
[+] [-] _pius|14 years ago|reply
What is the One True License? I prefer the MIT license and almost everything we open source at GitHub carries this license. I love this license for several reasons:
It's short. Anyone can read this license and understand exactly what it means without wasting a bunch of money consulting high-octane lawyers.
Enough protection is offered to be relatively sure you won't sue me if something goes wrong when you use my code.
Everyone understands the legal implications of the MIT license. Weird licenses like the WTFPL and the Beer license pretend to be the "ultimate in free licenses" but utterly fail at this goal. These fringe licenses are too vague and unenforceable to be acceptable for use in some companies. On the other side, the GPL is too restrictive and dogmatic to be usable in many cases. I want everyone to benefit from my code. Everyone. That's what Open should mean, and that's what Free should mean.
[+] [-] StatHacking|14 years ago|reply
I agree with everything but the "core business" stuff and the MIT License.
The same principles apply to your core business - independent of what it is (not only GitHub).
By opensourcing all of your business, you will gain all the synergy you mentioned (i.e. libgit2) within your core.
Your competitors will benefit from it, but they won't be a challenge to you as long as they don't have the passion and insights from your team. If they can find a way to do better than you with that knowledge (expressed as software), then your position in the market is based on imperfect information (and therefore, monopolization power).
Although you may have everything to start a DVCS frontend, it is not an easy task which doesn't rely only on software: you need the ability to understand the infrastructure needed for the problem and maintain it at a reasonable speed - armies of proficient developers extending and fixing bugs, armies of sysdamins, coordinate them, decide adequate directions, etc.
Besides that, you need passion about what to do in order to keep kicking asses. Without it, it is not sustainable in the long run. Think about Launchpad, I think they add extra functionality to bzr than GitHub to git, yet people still sticks to GitHub. Why?
Also if you opensource your "core", people will need also customizations, so your competitors can become your clients where you provide developing to them - they may target other niche that you can't or your are not interesting.
This is where the license comes in: the best way of achieving this is by using AGPL3.
With AGPL3, you make sure that everything you gave it won't be restricted to others - as you haven't restricted anyone by opensourcing it.
You are not restricting others' freedoms, they can do whatever they want with the software. When someone closes the source, it's restricting others freedom, not his. What you can't do with AGPL is taking away others' freedom and right to know what they are using.
If someone improves it, then it will come back to you, and you will be able to improve from others as they improved from you.
The MIT license is good, but it doesn't close the loop and may have leaks, :D heheh!
A hug from Uruguay, Rodrigo
[+] [-] danssig|14 years ago|reply
Good! Who wants their living standard to be dependent on a never ending rat race of constantly out-innovating competitors? Especially when there are really big players out there that can throw huge resources into taking your market share.
[+] [-] sjs|14 years ago|reply
What if they want to build something on top of it that is not open source? They cannot and that is a restriction. It is the definition of a restriction.
> When someone closes the source, it's restricting others freedom, not his.
How so? No one is restricted if somebody makes a private fork of a codebase.
That's like saying that if I don't go to the bar down the street tonight the people there are restricted from having fun.
[+] [-] fadisinger|14 years ago|reply
Fadi from Silverpeas
www.silverpeas.org (GNU GPL 3)
[+] [-] fadisinger|14 years ago|reply
[+] [-] beagledude|14 years ago|reply
[+] [-] jamesu|14 years ago|reply
[+] [-] king_magic|14 years ago|reply
I'll contribute back to the community happily. I do so because I want to. But I do not feel that I am morally obligated to do so. I'm sorry, I simply don't.
The author makes the point that one should give back, for example, simply because one "used the internet". It is one thing to say that you should open source your code and give it back to the community if it is derived in some way from another open source project. It is quite another to say that just because you use open source, you are now morally obligated to give back to the community.
All of you out there using an Android phone - do you feel morally obligated to open source your work simply because you use a phone that is built predominantly on open source code?
[+] [-] elliotanderson|14 years ago|reply
Some notable mentions: Active Merchant (payment processing library) Active Fulfillment (external fulfillment for Amazon/Shipwire/Webgistix) Active Shipping (shipping carrier integration) Delayed Job (job queue)
Obviously there is a lot more work that goes into making a product as polished as Shopify, but they have released a large amount of core domain knowledge for other people to use and improve upon. While someone might be able to come along and use the same components to create a competitor, they still win in the end by having more people contribute.
[+] [-] programminggeek|14 years ago|reply
You shouldn't open source your product itself unless you want to be a service company. I personally don't care to become a service company, so I keep the "product" and the data behind it closed, but the frameworks, tools, etc. can and should when possible be open source.
[+] [-] alexhawket|14 years ago|reply
[+] [-] cpeterso|14 years ago|reply
https://www.gnu.org/licenses/license-list.html
[+] [-] secoif|14 years ago|reply
Something along the lines of stable and opt-in unstable UI branches with frequent releases.
[+] [-] nicpottier|14 years ago|reply
If there's one thing time has proven it is that open source projects (usually) leave a lot to be desired in the UI department. UI is one of those things where a benevolent dictator is a good thing, it gives you consistency and given a talented designer leading the team gives you a far better product.
The typical path for for open source UIs seems to be to try to please everyone, which means making something that isn't great for most people who don't want to spend half a day customizing their interface.
[+] [-] hboon|14 years ago|reply
[+] [-] ptman|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]