135 days of commits and 50+ open source contributions later

It has been more than 2 months since I left Rackspace to work on my own startup. Those two months have been very busy and many different things have happened.

After a lot of development, brainstorming and working with our potential customers, David and I have decided to stop working on a project we originally started to work on after I left Rackspace (Wadodo) and focus our effort on two other projects.

I plan to go into more details why we have decided to do that in a future blog post, but it suffices to say that we have decided to focus our efforts on projects in other fields where we have more experience and connections (personal training, big data and distributed systems).

Wadodo

First of those projects has already been launched. It’s an online marketplace for personal trainers and athletes called CoachSpree. Second project is well underway and should be launched in the near future.

To make those products a reality, I have spent a lot of time on coding and non-coding (customer development and acquisition, …) tasks. In this post I’m going to ignore other topics for a moment and focus solely on coding tasks, more specifically on my open-source contributions.

Why, you might ask?

There are multiple reasons:

  1. It’s nice to look back and see things that have been accomplished.
  2. To encourage more people to contribute to open source projects.
  3. To show people there is always time to give back and contribute to open source projects, even while working crazy hours on a startup.
  4. To push myself to contribute even more in the future.

Open source contributions are good, yo!

During this period I have made more than 50 contributions to more than 30 different open source projects. A big chunk of changes I have contributed were smaller bug fixes and feature additions, but there were also larger contributions and feature additions.

Github activity graph (also includes commits to private repositories)

It’s also important to keep in mind that the sheer contribution size and number lines of code is not always a good indicator of how much time was actually spent working on the issue.

Some of the smaller bug fixes I’ve contributed took substantially more time than other larger contributions. The reason for that is that some of the smaller contributions were fixes for some really nasty edge cases. And as it usually goes, debugging nasty edge conditions can be very time consuming and many times it’s really hard to write a test case which reproduces the issue.

Some projects I have contributed to are listed bellow. This list excludes projects where I’m a primary author.

As you can see, there is a lot of Python, but there are also contributions in other languages such as JavaScript (Node.js), Ruby and Bash.

Conclusion

My goal is to continue and hopefully exceed this pace of open source contributions and giving back to the community in the future.

I also hope this post will inspire other developers to contribute more. I would especially like to see more smaller web agencies here in Slovenia to contribute more.

I know a lot of such companies who rely on many open source projects and technologies, but they run forks instead of contributing changes back upstream.

Lets ignore moral perspective and not giving back for a moment and focus solely on the cost of forking. From a quick glance and a short-term thinking, forking might seem like a time saving thing to do. It is true that it might save you some time in the short term, but in most cases it’s going to result in a lot of additional work and maintenance headaches in the future.

So keep that in mind next time you fork a project.