Modernizr, HTML5 Boilerplate and jQuery are just a few examples of well known projects which were born from a desire to put something out there that could help others on the Web do more. These projects evolved because developers started using them and thought, “Hey, I could do something to help make this better. I bet it could save someone else’s time if I shared this with the world.”
Web standards like CSS3, HTML5 and the foundations of the Web as we know them would also not have been possible without people (just like readers of this post) spending time researching use cases, writing proposals, implementing features and catering to existing and future requirements that could be used by everyone. When you think about it, both standards and open source projects have had a large hand to play in the Web as we know it today.
In this article I’d like to talk about how you can help give back to the Web and a new project that seeks to make this process easier: MoveTheWebForward.org. If you’ve ever thought about contributing to the community but weren’t sure just how, I hope this serves as a good starting point for your journey.
Why Help Move The Web Forward?
In most cases, developers and designers that contribute back do so because of an inherent passion or desire to either improve an open source project, Web standards or the quantity of educational material freely available online.
What you get back from this is (in my opinion) worth every minute of effort.
Contributing to open source projects, you can learn more about the intricacies of programming languages, libraries and standards implementations than you probably could if you were just been a passive user. This can help you gain a better appreciation for how the Web is built, but also improve the quality of the development work you do as a part of your job.
Whilst not the reason most people do it, open source involvement can also often lead to more fulfilling jobs (and occasionally more pay). Demonstrating you have passion (and skills) in a focused area can help highlight you to recruiters at companies where those skills are highly valued.
Finally, involvement can help improve your knowledge, whether it’s simply writing tutorials about standards for others, actually being involved in submitting patches or feature implementations to browser vendors and libraries or contributing to discussions in standards mailing lists (which I’ll discuss in greater detail shortly).
“For me, open source is not about giving back, but its more about being sociable with the developers you admire. I really like forming small groups to work on projects and challenges together, or just like-minded folks that chitchat and passively learn new skills regularly.
The community has given me back great friends and I think we’ve all found more ways to be fulfilled by the work we create.”
— Paul Irish, HTML5 Boilerplate, Modernizr, jQuery team
1. What can you do and how much time can you contribute? Before we look at what you can do to contribute back to the Web, ask yourself three very simple questions: What are your strongest skill-sets? How you might these be used in an open source project? How much time and effort would you like to contribute to giving back?
Understandably, a lot of us have full-time jobs and it can be tricky sometimes trying to fit in extra side-projects into our schedules. The great thing about the Web is that there’s never too little or too much time that you can spend moving it forward.
10 minutes is enough to help someone stuck on a Web-development problem and an hour here or there is enough to greatly improve existing open source projects. If you have the desire to give back, anything is possible.
2. Pick a project or Web standard/specification you would like to work on Once you have some rough ideas of much time you can contribute, you’ll need to decide on the project, standards group or area you would like to help with. The good news is that there’s a great new initiative to help with this called MoveTheWebForward.org (MWF), driven by some of the talented people that brought us HTML5 Boilerplate.
MWF is a project that aims to make it easy for anyone to get started contributing to the open source community.
Whether you’re just diving into Web development, or are have been doing it back since tables were cool for layout, there are a number ways for you to give back to the community. MWF makes it easy to help anyone find ways to contribute back to the Web platform by giving you a list of ideas, resources and guides to get you started.
Do you feel the implementation of a particular feature isn’t quite as usable as it could be? Are there circumstances where a solution just doesn’t give developers everything they need? The learnings you’ve obtained whilst using things on a day to day basis are something you can share with a project to help improve it.
Take a look at MoveTheWebForward.org each week and if you’re up for it, consider committing to getting a small task done that can push the Web forward.
3. What would you like your role in the project to be? Most open source projects (and standards groups) have a number of key areas that they require assistance with. In no chronological order these are:
- Core development
- Discussions / Mailing lists
- Bug submissions triage
- Site & UI Design
- Developer Evangelism
Depending on the project there may also be areas such as ‘specification writing’ that are necessary in order for features to be discussed before they are implemented.
Whilst beginners won’t generally be directly discouraged from trying to get involved with core development, it’s more often intermediate and advanced users of libraries or features that are better equipped to optimally implement code that is efficient, performs well and passes unit tests.
“I love open source. I’ve been hooked on jQuery since John Resig accepted my first patch in January 2006. It’s been at the center of several profitable projects that I’ve built. Contributing to both jQuery’s code and documentation just seems like the right way to pay that forward.”
— Dave Methvin, jQuery team
If you’re interested in getting involved with core development, I suggest spending time familiarizing yourself with:
- The build/setup instructions for the open source project you wish to contribute to
- How the project is structured so you can later experiment with making patches and running tests
- The project contribution guide. Most open source projects these days are hosted on GitHub. This means that filing patches is usually as straight-forward as filing a pull request, but make sure to follow the project’s guidelines on doing this. At jQuery, we require developers to file a ticket in our bug tracker to accompany pull requests but it’s a subtle step that we cover in the contribution guide.
- Where current contributors congregate to discuss issues, features and patches — with Web standards or libraries this could be a mailing list or an IRC channel. Mozilla has dedicated channels for people wishing to contribute to the MDN as do jQuery and many, many other open source projects.
"Whether you're contributing to existing projects or open-sourcing projects of your own, giving back to the community is a great way to learn about Cool New Stuff™." — Mathias Bynens. jsPerf, HTML5 Boilerplate
Discussions & Mailing Lists
Standards Mailing Lists
We all know that Web standards are important. They help ensure the code we write works across different technologies, for people of different abilities and most importantly across all browsers. If you have an interest in pushing the Web forward by getting involved with the standards process, there are a number of different mailing lists you can subscribe to (and participate in) should you have particularly strong feelings about the direction particular technologies or features should be taking.
These mailing lists include public-html, public-webapps, es-discuss, www-style, public-fx and WHATWG. I recommend spending time familiarizing yourself with how contributors to these lists approach discussion as you’ll want to ensure your posts are read rather than ignored - specifically, research proposals, read spec wikis where available and ask other posters for their input offline if you’re unsure about anything.
Note: Chapter 2 of Mark Pilgrim’s HTML5 book contain an excellent discussion of how standards get pushed through mailing lists. It also covers some of the evolution of standards through history and is a recommended read for those interested in grasping how the process works. You can read it for free online here: https://diveintohtml5.info/past.html
The jQuery Standards Team
While many of us would like to see change, the reality is due to time restrictions and lengthy formal processes we’re not always able to participate in standards discussions, get involved with writing specifications and contribute to meetings about the future of features. This can sometimes make it difficult for Web developers to have a voice.
Another problem is that for those that do get involved with the process, it can often feel like participating on a particular thread in standards mailing lists has a limited impact because the Web community is so fragmented. There’s also a lot of assumed knowledge required of existing discussions, decisions and historical context that can make it a little more challenging to get involved.
The jQuery project have set out to try changing this. They want you to have a voice in how the future of the Web is shaped which is why they created the jQuery Standards team. The standards team listens to suggestions or feedback you may have about current specs and if there’s sufficient interest in making changes related to your concerns, they’ll file tickets on your behalf in the appropriate format.
For more information see: https://github.com/jquery/standards
Code/Project Mailing Lists
Mailing lists for code projects (e.g jQuery, Dojo) tend to work quite similarly to those for Web standards. The only real differences are that discussions can sometimes be more fast-paced and generally target the resolution of features or fixes being targeted for a specific library rather than something as broad as a standard.
You don’t have to be someone that implements library code to be able to get involved with these discussions, but it does help having a good level of familiarity with both the library, alternatives to it and the general space being worked on. As per my early suggestion, spend a little time analyzing the best way to jump in with suggestions or ideas to increase the chances of having a positive impact on the conversation.
When most developers think about getting involved with open source, their first thought is usually about writing code that can one day be used by many others.Whilst it’s true that implementations are of course important, documentation is an equally if not more important part of the release process.
Think about it: when you first learn about a new specification that’s been implemented or about some new framework that’s just been released, your first port of call is to look at the documentation or the getting started guide so you can figure out just how to use it. Without this documentation, most projects (and indeed, specs) would be nowhere near as popular or widely used as they are today.
The great thing about documentation is that (unlike full-blown patches or implementations), your contributions can be as small or as large as your time permits. I’ve seen developers contribute simple one line changes to documentation whilst others have provided the equivalent of complete chapters of written docs because they wanted to make it easier for others to understand how everything works. If you’re good at writing, consider giving docs a try.
Writing docs is also a great way to increase your knowledge about how to use the software or tool you’re writing it for. If you feel comfortable using a particular project, consider looking at the bugs files on their trackers. This can offer insight into what confuses users and you can try writing out documentation for such workflows or actions that are unclear.
The barrier of entry is a little lower than core development and there are many well known open source projects that could use your help in this area.
Bug Triage (Issue Moderation)
Most open source projects (including frameworks like Modernizr and browsers such as WebKit) have their own issue or bug trackers. These are typically used as a central location where users can submit issues, feature requests and track the progress of what’s currently being addressed. As projects become more widely used, the number of issues received incrementally grows and there becomes a need for these issues to be moderated. Reasons issues may need to be moderated include being:
- Invalid. In many cases, users will simply submit issues with a project or specification without spending enough time debugging their solution. Sorting the invalid tickets from the valid ones makes it easier for core developers to focus on addressing the important ones.
- Duplicates. The issue may have been previously submitted. This is easy to discover as the majority of trackers have their own search options.
- Patch welcome. Where an issue is acknowledged but is beyond the scope (or time-constraints) of a project to patch itself.
- Won’t or Can’t fix There are issues users may submit which a project may admit is a valid problem, but which may not be currently possible to fix, either due to the direction the project is taking or the broader implications it may have on a codebase.
Moderators are usually required to help narrow down issues to a list of (valid) confirmed issues and feature requests. The great thing about being involved in bug triage is that you’re regularly required to evaluate code samples and establish why a bug may or may not in fact be, valid.
“Contributing to the development of open source software, such as jQuery and Popcorn.js, is my way of ensuring that the future is awesome - in both the things people create and the tools that they’ll use to create them.”
— Rick Waldron. jQuery team, Popcorn.js
You’ll often find yourself writing short solutions that address the problem as a workaround and the knowledge you build up from these can greatly help avoid the same problems if you run into them in other projects or at work.
Larger open source projects often have to deal with millions of requests for downloading their library every single day. Even when offering a CDN-hosted version (like we do at jQuery), they still have a large quantity of requests coming in to access their sites, documentation pages and official tutorials. None of these would be able to cope under strain without the hard work that experienced ops people have to offer.
“Being involved in operations has not only given me the opportunity to contribute and sharpen my skills with git, writing tests and streamlining processes, it’s also allowed me to meet some incredibly talented people and make fantastic friends. Contributing to open source has made me better. Period.”
— Dan Heberden, jQuery team
Operations (ops) also take care of some of the smaller day to day tasks like granting permissions for new contributors wishing to access different parts of a site, setting up scripts to help automate and streamline tasks and generally ensuring the visible public face of a project stays online. If you have strong ops skills, feel free to reach out to projects (both small and large) as they likely wouldn’t mind some more assistance, either now or at some point in the future.
Implementations of new browser and library features require an extensive amount of testing prior to being released. This covers everything from ensuring 100% unit test coverage is reached, tests are written (or provided) for any patches submitted and where applicable, tests are run across all browsers, environments and devices your particular project targets. If you’re a stiffler for ensuring code is stable prior to being pushed to end-users, you may be interested in helping out with testing efforts. Speak to current contributors to the project to find out their current need for members looking specifically at this area.
Site & UI Design
“Working on open source projects means you have the skills of several people to tap on. It is a great place to learn Web development, creating workflows that work for collaboration. Moreover, it’s safe - it’s not like you’ll get fired for testing things out. The projects I contribute to are directed towards problems I struggled with myself and wish other designers had.”
— Divya Manian, HTML5 Boilerplate
Evangelism & Support
The role of technical evangelists varies quite a lot in open source projects. Its goals can include:
- Supporting developers in the community by providing assistance, answering questions and making it as easy as possible for developers to solve problems they may be running into (doing so via IRC, Twitter or forums is quite common).
- Working with developers in the community to help understand why particular standards, browsers, libraries or tools should be used and can make developer’s lives easier.
- Writing tutorials, creating screencasts and building demos that help educate others.
- Generally speaking on behalf of the project at events to further enhance awareness about the project’s goals and offerings.
- If you enjoy helping people solve problems or have a passion for writing (but aren’t a big fan of writing documentation), consider giving evangelism a try.
Share Knowledge, Share Experiences and Build New Things
Beyond assisting with the goals of a specific code project or standards working group, there’s a an array of other useful things you could be doing to help push the Web forward.
Building Many of the most popular open source projects today once started out as tools and workarounds that a developer or designer worked on to satisfy a personal need. If you love hacking on code, please consider sticking your work up on GitHub and sharing it with the rest of the world. There may be many others (just like you) that your work could end up helping or inspiring it’s a great feeling knowing that you’ve saved someone else from dealing with the same headaches you once had to yourself.
Blogging Although I’m involved in open source projects, my biggest contribution to the Web is still in my day to day technical writing. Teaching through this medium is a great learning tool and you’ll often find yourself learning more as you write and research about the topics you’re conveying.
Remember that your words can be a very powerful tool for pushing education on the Web forward. For this reason I encourage you to consider writing about what you do and learn — write tutorials, create demos, post gists, write essays.
“After being repeatedly nudged by people to start writing about changes to WebKit and Chromium, which I had been monitoring for a long time already, I wrote my first article back in August 2010.
To date, 64 articles have been published and many more people are aware of and get involved in the implementation of cutting-edge features at both projects. I myself am now part of the Google Chrome and WebKit teams, focusing on improving both the browser as the Web, doing that which I love to do.”
— Peter Beverloo, Google Chrome team
Don’t be afraid to make mistakes (because that’s how we all improve). It’s absolutely okay for you to not be a complete expert or authority on a topic. Share what you do know because it has the potential to help many other developers and designers out there. Reach out to others in the community if you don’t know something — ask questions and prompt conversations.
The Mozilla Developer Network, also known as MDN.
The MDN is a community of developers building resources to improve the Web, regardless of what browser or platform you’re using. Anyone can contribute to it as the entire site is a wiki (just like Wikipedia). There are sections that detail specs, pages that are just tutorials and others that are just guides to quirks that are useful to be aware of when using particular browser features.
“When I learned about Web standards not much was available out there. The Mozilla Developer Network was one of the first resources I kept going back to when I was stuck. The reason why it still is that way is that it is a living resource that anyone is invited to edit and keep clean.
It is pretty rewarding to be part of this and knowing that what you put on the Web is part of something that by definition is there to keep the Web free, open, and make it easier for the next generation of Web makers not to have to make the same mistakes we did to build something good for the Web.”
— Christian Heillman, Mozilla
To give you an example, here’s a page I fleshed out during one of the MDN sprints with (reliable) links to get started with learning Web development: Introduction to Web development. Simple, right? It’s nothing more than an organized page of links, but prior to the new learning section on the MDN site being launched, it helped developers and designers get started with basic fundamentals when they were unsure where to look.
Mozilla evangelists regularly hang out in
#mdn on irc.mozilla.org (IRC) and are always happy to help new contributors get started if you have any questions. Consider giving it a try!
That’s it for this guide. I’ll be sure to update it if there’s anything I’ve missed out on, but I hope it inspires others to consider giving back to the Web platform. Remember to check out MoveTheWebForward.org if you’re interested in picking a task you can start working on today. Together, we can help move the Web forward.
- Dear Web Design Community, Where Have You Gone?
- The Web Design Community Offers Advice To Beginners
- Teach Them How To Hit The Ground Running And Faceplant
- The Sad State Of The Web Design Community
With special thanks to Divya Manian, Nicolas Gallagher and Paul Irish. Images courtesy of the 56 Geeks project.