why do you contribute to other’s repositories?

I’m interested to hear from other open-source coders out there. I’d like to know some of your motivations for contributing to another person’s or another team’s open-source repository. Call it a social studies experiment, if you will.

1st-Person Open-source

Here, I’m attempting to answer the question for everyone: “Why do you work on your own project in a public way and sharing your source code, knowing full-well that someone may take your code or fork your project and become rich and famous as a result?”

  1. I believe that my project has some worth for others and sharing it could make the world a better place to live in
  2. Other people might help me with my project
  3. A well-rounded github set of repositories looks good on my résumé
  4. I’m not expecting to make money from doing this
  5. Since I don’t live in America, there aren’t as many opportunities so this is my way of getting some attention from potential companies there

Let me know if I’ve missed any motivations here.

2nd/3rd-Person Open-source

This one’s a little trickier for me since I’ve been a life-time coder. In the not-so-distant past I was well-paid for working on software projects and have watched the coding salaries and the availability of programming gigs all erode.

The next question then for everyone: “Why do you work on someone else’s project in a public way, fixing their bugs and adding features, knowing full-well that some else may become rich and famous as a result?”

Case study – Github: Bloomberg reports that they recently brought in another $100M in venture capital based upon the Enterprise-level private repository revenue they’re currently earning. They’re currently valued at US$2B.

  1. I really like the other project’s code (let’s say, the Atom editor), believe in it and want it to be more awesome than it already is; since I use it myself, I’m getting something from the collaboration
  2. I want to work on a big project but I can’t otherwise get a job in a software development company so this is the next best thing; I’m getting the experience working in a software development team
  3. “Many hands make light work”; it feels good to help others; karma; “what comes around, goes around”…
  4. As a new programmer, I don’t have enough experience to start my own project yet
  5. Since I don’t live in America, there aren’t as many opportunities so this is my way of getting some attention from potential companies there; I might get hired by doing this

If I’ve missed any of your own motivations for coding on other people’s/team’s open-source projects, please add a comment here.

Some Thoughts on the Open-source Subject

What’s strange is when you have an entire team of people spread all over the planet, they’re working together on a project started by one guy (let’s say), time goes by, the project goes viral and then suddenly one day that “one guy” gets $250M in venture capital (like in the case of github). It’s valued at US$2B at the moment, btw. That’s about the same value as the New York Times.

I wonder if the investment companies realize that for the average open-source “company” this means that 1) they’re not necessarily incorporated, 2) they probably don’t have an office nor even a business checking account, 3) and anyone can fork the collection of code and start their own Atom-knockoff project if they wanted to.

And what happens to all the people whose free labor went into making github who they are today? Do they get a share of the money? No, they don’t. Do they get a job? Possibly, I suppose it all depends upon that original guy. But at this point, the power has greatly shifted from what it was before (more of a democratic society) to what it is now (more of a capitalistic corporation).

The siren call of open-source is a world which is free from capitalism. But what seems to happen is that these big projects are becoming exactly that, the thing these coders hated in the first place (or so it would seem). Open-source is supposed to be a culture. So why is it turning into nothing more than a first step to becoming a (funded) software development corporation in the end?

what the fork?

fork noun repository

A copy of a repository’s master code, allowing one to freely experiment with changes without affecting the original.  This also includes a complete departure for the purpose of doing something differently from the original author’s design and sometimes without intent to merge code back into the original master branch.


The question for project managers would be “Is there a natural risk for open source software projects with respect to forking?”

Open source is wonderfully organic in that it grows like a plant.  Branches are created overnight, branches may or may not be maintained by others and some simply wither away.  Like plants, some software branches are buggier than others.  We acknowledge though that our own programs are made up of a collection of the code from these repositories.  At the moment of truth when we decide to include some particular bit of code we make a reasonable assumption:

Over time, I assume that this included code won’t change so dramatically that it no longer serves my own purpose or that it will break my own code.

Can we honestly take on that risk for our own venture given the usual number of dependencies in a typical Node.js project, e.g.?  Most open source code doesn’t de-evolve quite so destructively usually since it hasn’t reached a level of fame yet.  But for some code that enjoys thousands of downloads this necessarily means that many people now are suddenly very interested in the future development of that code.  And if this public forum is anything like the inter-department conversations of an average software development company then you may assume that different parties will have differing ideas about what that future should look like.  And this then is the risk that we take on:  In the future someone else may steer that dependent code in an incompatible direction from our own.

Size Matters

You’d think that each person in the open source arena would have equal say regarding future suggestions and modifications to commonly-used code.  I don’t believe that this is the case, to be honest.  Big players like Google actively participate in the world of open source.  Given their size and the number of developers they can throw at anyone else’s code they could easily steer development efforts into a direction which suits their own needs.  In a way, you would think that the world of open source would operate on merit alone.  The reality could easily be that open source is very much at the mercy of anyone with the wherewithal to dominate the playing field.

Adobe’s PhoneGap promotes Cordova behind the scenes for multi-platform phone development.  Given their level of commitment this will likely mean that over time competing technologies may not succeed.  If you choose the wrong technology you could abruptly lose support in the future when some dependent code author decides to hang it up and do something else.  Big players like Adobe can enter this space almost overnight and quickly change the playing field for everyone else.

Fork-300x199

The Fork in the Road

Personally, I use jQuery and jQuery Mobile in my own software.  What would happen in the future if somebody there at the jQuery Foundation decided to change up the fundamental ways that the interface works with PhoneGap, the development platform I’m also using?  I then find myself as the helpless passenger inside a carriage I’m not piloting suddenly careening down some path I didn’t envision.  Not only would my code break for some single build but I might then need to re-evaluate bigger decisions like platform and dependency selections.  It might be necessary to even consider throwing labor at jQuery development as an option.  If I do choose to depart from the direction they want to go then I necessarily lose support over time as a consequence.

It just strikes me as a long-time software developer that we could use some risk management strategies for what we’re taking on into our projects as these dependencies.  Is it then necessary to read outstanding issues on a per-dependency basis and to haunt those discussions?  I hope not.  I don’t think that the average coder would have that luxury of time on their schedule.