15 October 2010
(This is a repost from the HipChat Blog)
Open source projects depend on community cooperation. Successful projects have a healthy group of individuals and companies submitting code, writing documentation, and testing new features. Unfortunately it’s not always easy to contribute because different projects will use different bug trackers, version control systems, and approval processes. Package maintainers also have a hard time handling all the incoming patches in a timely manner which frustrates the contributors.
In 2005 Linus Torvalds created the Git version control system in order to solve problems he was having dealing with patches to the Linux kernel. A few years later GitHub came along with a nice web interface on top of Git, making it trivially easy to fork, patch, and contribute to projects hosted there. The standardized wiki and issue tracker features mean that many projects are setup in the same way. Once you learn how to contribute to one project on GitHub you know how to commit to all of them.
Unfortunately GitHub makes it so easy that I’ve found myself becoming lazy. It feels a lot harder to contribute to non-GitHub projects because it often requires signing up for their custom bug tracker, learning the patch process, and waiting longer before the patch is accepted. That extra friction is sometimes enough to prevent me from submitting a fix, and that’s not good for the project.
Ease of contribution is clearly an important factor for open source and other community-driven projects (just look at Wikipedia). As GitHub continues to grow, are more projects going to feel pressure to switch? I think they will, and I’m looking forward to it. Better software is good for everyone.
13 September 2010
(This is a repost from the HipChat Blog)
When we’re at conferences and meetups there are always a few people who come up to us (probably because of our awesome shirts), hear what HipChat is, and say “Couldn’t I just setup my own Jabber or IRC server for free?”
“Yeah, but you wouldn’t get the slick UI, drag-and-drop file sharing, searchable history, and all that. Plus, you’d have to manage the system and teach people how to use it.”
For some reason these points never resonate with this type of person. Solving 10% of a problem by themselves is good enough. What they don’t realize is that people are very willing to pay for the convenience of a hosted service and the things that come with it: a cleaner and more consistent interface, support, frequent updates, and peace of mind. I imagine many startups run into this type of response at some point. Here’s how a DIY mind may have responded to some services which are now very successful:
- Cloud computing – “Couldn’t I just buy a cheap machine and stick it in a colo?”
- Flickr – “But I could build my own photo gallery using PHP in 20 minutes!”
- GitHub – “But git is open source software. Why would I pay you when I can just run it locally?”
- Google Apps – “Can’t I just run my own Postfix server and set up Horde?”
I’d like to challenge all you do-it-yourselfers to think about the problems you’re capable of solving and how many people could benefit from the solution. If it’s a fair number of them you probably have a great idea for a startup. There are a ton of people and companies out there. Sure it’s fun to solve problems yourself, and it’s a great way to learn, but keep your mind open. There’s always room for improvement and that’s a great way to make money.
08 August 2010
The git-hooks project provides a way to run git hooks locally before you check in your code. This is especially useful if your code is hosted on GitHub because you don’t have access to install server side hooks.
From the README:
Hooks can be very powerful and useful. Some common hooks include:
- Spell check the commit message.
- Check that the code builds.
- Verify that any new files contain a copyright with the current year in it.
Hooks can be very project specific such as:
- Verify that the project still builds
- Verify that autotests matching the modified files still pass with no errors.
- Pre-populate the commit message with the ‘standard’ format.
- Verify that any new code follows the ‘standard’ coding style.
or very specific to one person such as:
- Don’t allow a push to a remote repository after 1am in case I break something and will be asleep.
- Don’t let me commit between 9-5 for projects in ~/personal/ as I shouldn’t be working on them during work hours.
I wrote some hooks for checking PHP syntax and checking Python files using PEP-8 and PyFlakes.
Hopefully they’ll integrate this functionality into the git core at some point.