Virtually every application we push to production relies very heavily on open source code in one way or another. This means we’re utilizing the experience, knowledge, and expertise of the OSS (Open Source Software) community to solve many of our problems. Things that would’ve taken us quite a bit of time, money, and effort to iterate on in order to bring the quality to something on par with the OSS options are freely available and open for us to incorporate in our projects.

OSS is smart for us and smart for you since we’re often able to expand our knowledgebase and our expertise channels just by using the software and being a part of the community, something we do actively and constantly.

We contribute back as often as we can: bug fixes, new features, documentation, and sharing knowledge whenever possible. This is the essence of open source: the users of software giving back their own time and experience, especially when it benefits everyone.

Our standards for OSS remain high: we require that libraries and frameworks

• be well tested

• be well documented

• be implemented sanely: organization, style, dependencies (for debugging and contributing), and

• have an active community or maintainer

Tests give us confidence that the library works the way its described. A solid Readme and API docs gives us enough information to start using it and know where to turn when we need to know more. Sane organization makes debugging easier, contributing simpler, code spelunking more fun (because sometimes we just need to dive right into the code to solve our problems). Without an active community or maintainer, bugs will go unfixed, software will continue to rot (falling behind changes in more active projects like Rails), etc.

We constantly experiment with new libraries and tools all the time, but ultimately we make decisions that are in line with these requirements. Without these guiding our decisions, we could easily get caught under the bus when it becomes apparent software is broken, unusable, poorly documented, and unsupported externally.

Lets take a step back to one library we use constantly: Rails.

Rails

Yes, even Rails had to pass our requirements, and it does so with flying colors in case that wasn’t obvious. So much so that we’ve devoted ourselves to mastering application development primarily within its ecosystem.

How does it stack up to our requirements?

• Rails maintains a very detailed and extensive test suite, is fairly well documented internally, and has countless sources of external documentation through blog posts and on sites like StackOverflow.

• Rails isn’t just one big mess of code, either: it’s broken down into well organized modules and support libraries like ActiveModel, ActiveSupport, ActionDispatch, etc. And to tie it all together, each package provides a good deal of hooks to make getting deep into it very easy. This gives us quite a bit of power in our day-to-day development and for debugging when necessary.

• The Rails community is stellar: so many bright developers are constantly building excellent libraries, tools, and applications with it. We’re never at a loss for an answer because the community spreads knowledge so quickly and effectively. The core maintainers who organize the roadmap, handle bug fixes and accept patches, and work on new features are some of our personal heroes.

Rails isn’t always a perfect fit for every web application we build: Sinatra and Rack are on our short list for memory sensitive and fine-tuned performance applications that don’t require the development features that Rails provides. But even then, Rails 3 has opened even more doors for Rails to rock.

Rails isn’t great for any one reason, but if I were to choose which requirement Rails meets best: its community is by far its strongest proponent.

Next Up

Have any libraries, tools, or applications you want us to cover? Leave a comment below!