A little more than a year ago, we started something unprecedented in my career here at Viget: We made the decision to make some of our code freely available to the public. The software was Tyrant
, and while we haven't put together an "official" release, this first effort was enough to spark an interest in releasing more of our work to the larger developer community. A few months later, we reconvened to discuss ideas for Rails plugins that would be useful to other developers. After a lively discussion and some good ideas, we left the meeting feeling invigorated with plans for a new VPS to host both a Trac installation
and a public-facing Subversion repository
. Some of those original ideas died out, but others live on
as active projects
, and even more have been created
as we encounter new challenges. This is all part of the life-cycle of a healthy open source ecosystem, where new approaches to problems and changes in technology give way to better solutions.
After seeing some of our projects gain attention
, and from tracking other open-source efforts, we've noticed a few common elements. Successful projects are:
- Effective – they focus on solving a common problem.
- Accessible – they make it easy to install and start using the software.
- Collaborative – they provide tools to allow others to easily contribute to the project.
The best way to gauge the effectiveness of any project is to get it in the hands of as many active users as possible. By leveraging tools that allow us to release "early and often" and receive contributions from our users, we will give our projects a better chance of flourishing.
To-date, we've been using Rails' plugin capabilities to provide enhanced functionality. While this gets the job done, it falls apart in two areas:
- It requires the user to provide an unwieldy SVN URL to the ./script/plugin command.
- It prevents us from easily splitting out common functionality into separate dependencies.
The recent addition of the config.gem
feature will change how developers enhance Rails' functionality and will allow for better dependency management. Instead of complicated SVN URLs, a simple rake gems:install
is all that's needed to get the latest dependencies for a project. In the past, our strategy was to run an external Gem server that provided an easier way to get the stable versions of the Gems that we were releasing. In order to make this more accessible, we've created an account on RubyForge
that we will instead be using to distribute our Gems. Now, getting the latest code is as simple as gem install constant_cache
Given our recent Git love-fest
, it's no surprise that we've been eagerly awaiting
the official launch of GitHub
. Git is great for collaborative development and GitHub makes it even easier for us to accept patches from people using our software. What does this mean for Subversion? We'll continue to maintain our external repository for a while as we resolve dependencies on other projects, but that will give way to using our main GitHub repository
for our open-source work. The "official" codebase for each project will live in the main account with each Viget developer (and others) forking the code to add functionality.
What's the Point?
As a team, we are always learning new ways of solving problems; opening our code to a larger developer community allows us to benefit from others' experiences and serves to better battle-test our implementations. So, have at it, and then tell us what you think. Being brutally honest will be the best way we can continue being active participants in the evolution of our community.