traveling at the speed of open-source

pull request:  An external-repository modification to someone else’s code which you’d like them to adopt into the master copy of the original repository, specifically the notification request to ask for this.

It’s funny, I put in a pull request in March of this year for a timezone calculation bug which I’d discovered somewhere out there in someone else’s code.  I guess I was trying to be a good net citizen and giving back to the community.  I’d forgotten completely about it until now.  The original author merged my commit into his code yesterday and blessed it, basically.  This would actually be my very first pull request in the world of open source so I suppose that’s special in some way.

In this particular case, it took the author almost three months to see the request and get around to responding to it.  Granted, few of us would be paid to maintain our open-source repositories so they’re usually just considered hobbies for most of us, something we do in our spare time.

As a coder with many decades of experience, this pacing is a bit odd to me.  (As in, “wow, three months to bless a quick-and-dirty code fix”.)

I’m not complaining…  Okay, maybe I’m complaining.  Maybe I was just a bit naive to the average amount of effort people are putting into this.

The entire collective force of open-source is something to behold.  Almost every day some huge effort is being launched and thousands—even millions—of downloads occur from these repositories.  But what happens to the original codebase when the author gets side-tracked with their next great idea?

But what happens to the original codebase when the author gets side-tracked with their next great idea?

The New, New Thing

All this reminds me of the biographical book “The New, New Thing” about a serial-entrepreneur, Jim Clark (of Netscape fame).  The biography doesn’t really paint a pretty picture of the billionaire, instead suggesting that he was perhaps suffering from Attention Deficit Hyperactivity Disorder (ADD) or possibly Hypomania.  He couldn’t focus on a project after the second year, opting to push the work onto others and move to the next project.

I guess I have to ask what part this plays in the world of open-source software.  As an inventive person, I stare at my To-Do list of project ideas and realize that it could be argued that this is some mark of my own internal restlessness.  Could I be content working on one project for year after year?

I’m a former CEO and at one time I did run a software development firm for nine years.  Fortunately, though, I had project after project then to develop so that kept things lively. I’m impressed by those who literally spent most of their lifetime devoted to a single project.

A Lifetime of Service

Dr. Royal Rife comes to mind as one of these people.  He was curing cancer and a variety of diseases back in the 1930 decade but he spent much of his life before this inventing the microscopes and medical device equipment which he would use in the culmination of his life’s achievement.  His original home site is now the location of one of the Scripps hospitals here in San Diego but seemingly nobody knows his story.  He spent a lifetime curing cancer and he isn’t famous for it.

I guess we as a society aren’t really conditioned to reward and remember someone who did one thing very well.  To be famous or respected now, presumably you have to produce project after project, never satisfied with the maintenance of same, always chasing the next big thing.

If You Build It, Own It

I guess my word of caution in the world of open-source then is to own what you’ve built.  Try to revisit it from time to time, like you might keep a plant alive by watering it once in a while.  Do new things, of course.  But don’t forget that your last thing could actually be ticket to your success.

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.