
Open Source (Almost) Everything - mojombo
http://tom.preston-werner.com/2011/11/22/open-source-everything.html
======
sogrady
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.

~~~
RyanMcGreal
> 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".

~~~
bh42222
_Google jealously guards their PageRank algorithm because it "represents core
business value"._

Given how popular Google bombing has been over the years, and SEO now, can
PageRank's functioning still be considered "secret"?

~~~
jordanlev
I believe you are missing the point of the argument. Substitute "PageRank
algorithm" with "whatever method(s) they are currently using to rank pages" as
it is always changing in response to people who are gaming the system.

------
pnathan
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.

+1, GitHub.

~~~
alexhawket
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.

~~~
tome
_One simple rule of business: commoditize your complements._

I'm surpised no one else has mentioned that. It's a very powerful idea, and
essentially what this blog post is getting at. I don't know if Joel Spolsky
coined that phrase, but that's where I first heard it:

<http://www.joelonsoftware.com/articles/StrategyLetterV.html>

------
chubot
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.

~~~
mweibel
Couldn't agree more.

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
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.

~~~
pavpanchekha
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.

------
kiba
Sometime I wonder if it is possible to open source everything without becoming
some sort of service company, like Redhat.

The only example I can think of is makerbot industries in which their core
technologies are open source.

~~~
dhx
GitHub _is_ service company.

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.

~~~
cschep
Certainly no one would buy the enterprise version of Github if it was free
though. Just a thought.

~~~
quadhome
In the same way that no one would buy RHEL?

~~~
audioHack
Complexity of self-support versus value of paid support.

Something like RHEL, the support is worth it to many businesses.

Something like Github... I could see it being less of a priority once it is up
and running.

~~~
dhx
The costs of setting up a geographically redundant GitHub clone and
continuously updating software and configuration are far in excess of the mere
$200/month GitHub charges for their Platinum plan: unlimited users, unlimited
public repositories and 125 private repositories. Even the Bronze plan for
$25/month with 10 private repositories is exceptional value to businesses that
only develop a few pieces of software.

At GitHub's price points, a manager would be crazy to take on the risk,
expense and effort of setting up their own clone. The obvious "but..." excuses
don't even apply because:

1\. GitHub offers enterprise "run GitHub from your own server room" services
for companies that have greater needs for confidentiality/customisability.

2\. Private organisations can take their source code and other data with them.
This means that users are free to move elsewhere (regardless of whether GitHub
is entirely open sourced) if GitHub suddenly decides to charge
$1,000/month/user.

~~~
bad_user
And how many businesses really need support for _geographically redundant
GitHub clones with continuously updating software and configuration_ ?

If anything, them having this option at all makes no sense, as the real value
of GitHub is in the collaboration and discovery tools it brings, useful for
contributors working remotely.

 _Unlimited users, unlimited public repositories_ \-- I have that on my own
VPS. I just configured my own Git repository. It's a piece of cake. Even
companies like Adobe get along just fine with a Wiki and a Perforce
repository.

Basically when selling a product or a service, you do have to ask yourself:
how big is the market for this? And I'm not seeing many companies really
needing private installs of GitHub and that market is even smaller if the
product would be open-source.

------
SeanLuke
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.

~~~
halostatue
What license would you recommend instead, for those of us who prefer not using
share-alike licenses (e.g., the GNU GPL)?

~~~
ajross
The Apache license is generally considered to be the most bullet-proof of the
non-copyleft open source licenses. It's what Big Corporations generally use
when they don't use the GPLv2. The MIT and BSD text is significantly shorter
and less formal.

------
pm90
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.

------
peterbe
Reason for working on a PRIVATE repo?: Committing code to side-projects during
work hours.

~~~
trafficlight
Commit locally. Push in the evening.

------
cmurtagh
"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.

~~~
wbkang
It's because the software does not link with Ruby or Git. It's just like most
people don't mind using GNU userland tools...

------
tomp
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.

~~~
frewsxcv
Just a simple difference I know: Do you want to force users of your code to
attribute the code to yourself? Then pick MIT/Apache

~~~
Dobbs
A much better reason is that you can't easily put things in the public domain
and many countries don't recognize the public domain.

------
StatHacking
Tom,

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

~~~
beagledude
so you think Google should open source their search algos?

~~~
StatHacking
Yes, I think so - especially with algorithms: math can't be owned.

On Google's implementation of them, yes, of course! This would have tremendous
impacts and benefits for all.

I think your sarcasm came from "What happens with Bing? They are hungry!", and
you can't understand the point inside that reasoning framework.

If Goog releases their algos, the would gain even a better position in the
market.

All the society would benefit of controlling what makes you exists for others
(if you can't google it, it doesn't exists), a storm of commits improving it
would come (even fixing what makes that disgusting SEO practices) and you will
have a viable alternative to Google: you will be able to choose.

Can Microsoft manage an infrastructure as big and efficient as Google - tuned
over the years for a SE, with thousands of people with expertise, experience,
motivation and values? I think not.

If Goog releases under AGPL, if Bing uses it, they will be able to look at the
implementations, its improvements and merge them "back".

If Microsoft doesn't want to use the code, then they will have to spend years
developing the same (and find the right people for it - which are already in
Google). In that timeframe, Goog will keep improving - otherwise, a better
alternative will eventually surpass them.

Yes, the can plain steal and don't enforce the license, but, Microsoft
stealing?!?!?!? =P

This model relies on two things: \- You are willing to work continuously on it
because it makes you happy \- You want to be on top because of how you do your
job, not because you know a secret \- Money is irrelevant to you: you live
(luckily) between 80 and 100 years, and suppose that you are on your 30s - if
I was given 100 million dollars, I will probably not be able to spend them as
I won't have time to do it (think Larry Page or Billionaires, but at a smaller
scale). If you get a huge amount of money, after some years of "livin; la vida
loca", would you return to code?

I would.

------
jamesu
I'm currently debating whether to release the source to one of my dead
projects, so the reasoning in this article is quite intriguing.

------
king_magic
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?

------
elliotanderson
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.

------
programminggeek
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.

~~~
alexhawket
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.

------
cpeterso
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.

<https://www.gnu.org/licenses/license-list.html>

------
secoif
I like to imagine how awesome github's potential UX could be be if they
decoupled, open-sourced and _allowed contributions to their front-end_.

Something along the lines of stable and opt-in unstable UI branches with
frequent releases.

~~~
nicpottier
What?!

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.

~~~
secoif
To be clear, I wasn't actually thinking about 'design', more like, features.
Perhaps you're right, and perhaps I'm longing more for some kind of plugin
architecture.

------
ptman
Is the github subversion server (backed by git repos) open sourced?

