Last week we released Foundation 2.1, our fourth release in as many weeks. We're really excited about Foundation, and equally excited that so many of you share our zeal for this framework. We wanted to take a couple minutes and show you how maintaining and extending Foundation fits into our workflow, so you can draw some ideas on how you can do even more awesome stuff with your products (or maybe and open source project).
Keeping Busy
We stay very busy here at ZURB, working not only on numerous client projects but also on our own apps like Notable and Verify. In the midst of all that we also developed and now continue to work on Foundation, so we have a few tools and processes that help us out.
Git and Github
There are quite a few people working on Foundation at any given time, both inside and outside ZURB. We use Git to keep track of versions and commits (thanks in part to a pretty slick native OS X app) but we also use Github to keep on top of bug reports, feature requests, discussion and contributions.
We've found tagging to be very useful when it comes to staying on top of issues, and we're fairly disciplined about when issues get closed down.
Deploying Updates
We use a few criteria to determine when and how to release updates to the public. This relates specifically to foundation.zurb.com, not the repo — the Github repo contains the bleeding edge code at all times.
- We push a minor point release when we're confident that the bugs we ironed out are squashed, we've tested cross-device and cross-browser, and we've resolved a decent number of issues or feature requests.
- We push out a major point release when we've added significant new functionality on top of the usual bug fixes and minor features.
- We'll push out a full new version when we've rearchitected sufficiently that the framework is no longer fully backwards-compatible. This is a ways out still.
When we're ready to release we have a local Ruby build script that takes an up-to-date local repository and packages all of the root files (without the marketing or documentation sites) and turns it into a single downloadable file. The script takes all of the JS (except jQuery) and packages it into foundation.js, then takes all the CSS (except app.css) and packages it into foundation.css.
We did it this way on the assumption that most people downloading the framework from the website are interested in building quickly and deploying rather than hacking away on the framework — by combining files we can eliminate requests which on a mobile device could have very high latency and thus a long delay to load.
Managing Time
Between issues, emails, tweets, and actual code you can imagine that Foundation could take an awfully large chunk of our time. With everything else on our plates we have to keep a few things in mind:
- The key to success with the public release of anything is to stay on top of it. We try and respond to every email, every tweet, every issue within a day.
- Foundation needs to not only support outside users but also our core services. We use Foundation for our client projects, both to deliver final code as well as to responsively prototype wireframes and interactions. We have to maintain it as rock-solid, proven code for our clients.
- It's not a one man job. Our entire team is involved in Foundation, either directly coding on it, spreading the word about it, or using it day to day and giving feedback.
Foundation is a lot of work, but it's extremely rewarding. Thanks to all of you for helping make it so successful, and we hope this little picture of how we work on it gives you an idea of how you could contribute and help us make it even better. Let us know in the comments, or on Github, what we could be doing to improve the framework and how you'd like to contribute!