At each Open Source Comes to Campus event, participants ask unique, thought-provoking questions. We decided to write down these questions and answer them more fully on our blog. If you have any additional suggestions or advice, please add them in the comments!

These questions are from our UMass Amherst event.  This post was co-written with Shauna Gordon-McKeon.

Why do we focus on bugs in the bug tracker, rather than adding new features?

One student asked why in Open Source Comes to Campus’s project time, where we help students make their first contributions to open source projects, we focus on bugs rather than features. From what I could tell, this came from not understanding the wide variety of items that appear in a project’s bug trackers, so I took a minute to explain that.

Bug trackers in an open source project are used for tracking progress on all kinds of work. They’re intended to be action-oriented to-do lists, not necessarily just lists of known times a program will fail. This means all sorts of items show up in them:

• suggestions for how to change the project’s website
• bugs, such as inputs that will cause the program to crash
• feature requests by users
• known issues in the current code, such as suggestions by the maintainer on how to improve the code’s layout for clarity

Having said that, we do focus on small tasks in the project time, many of which are small bug fixes or documentation changes. In the 3-4 hours students have, there is a lot to do: get acquainted with the internals of a program, gain enough proficiency in the tools around the project to create a patch, and work with a mentor to make sure it is a precise, correct fix to an issue.

Why are there multiple IRC servers?

To summarize: there are different IRC servers because different people seem to enjoy running the IRC server software for their particular chosen communities to communicate. One great reference on IRC history is this page by Daniel Stenberg, the maintainer of cURL.

To understand that, it’s helpful to know a few things. First, IRC is a protocol, not a centralized service. Second, IRC has the ability to have multiple servers collaborate to appear as one “network.” Third, different server/network operators have different goals, which result in different policies and often the creation of new networks.

Internet Relay Chat is a loosely standardized.  The standard lets people write their own chat programs (clients) and servers (also known as daemons) if they want to. Rather than being carefully designed as a protocol that would permit creating lots of different clients and servers, the standard simply evolved out of the first IRC client and server.

When you choose to connect your IRC client (for example, X-Chat) to the Freenode IRC network, you could be connecting to any one of a few different physical servers; you can see a list here. Any of those servers should act equivalently; you can talk to any user on any server on the network. (When this interconnectivity fails, it is known as a network split, also known as netsplit.)

While freenode is the network we use at Open Source Comes to Campus, and for the OpenHatch IRC channel, it is not the only IRC network. For one example, Debian (a free software project) uses OFTC as a result of disagreements about the way the Freenode staff ran the network in 2002. Freenode and OFTC are themed around community projects, but other networks exist purely to support chat, or to support chat about particular topics. At the small end, tech companies often run their own IRC servers for private use, and services like grove.io offer help running those servers. At the large end, you can see how popular other “top 10” IRC networks are in this netsplit.de graph.

What can you use Git/Github for, besides code?

You can use Git to store almost anything, provided you have enough space on your computer, and/or on Github, to house it.  Github is especially useful for plain text files, including program files, because Github allows you to easily visualize changes to plain text.  You can do a diff and see where characters have been inserted and deleted easily.  With an image, you can store the information about which pixels have been altered but reading that in text form won’t mean much to most people.  Github also allows you to edit plain text files directly from the browser.

So what kind of text-based projects can be versioned with Git?

• There have been several efforts to keep track of legislation via version control systems.  For instance, Gesetze follows the German Bundestag.

• The White House has put part of their open data initiative on Github and has been accepting issues and pull requests.

• The city of Chicago has started sharing its open data via Github.

• Hundreds of people have put up repositories of poetry, and a friend of mine uses git to keep track of her novel.

• Even more people have put their resumes on Github.

• Some educators are sharing syllabi.

• Some scientists are publishing their raw data, as well as the scripts they use for processing and analyzing it, on Github.

• I (Shauna) have a repository for scans of a weekly newspaper from the 1870s.

How do open source projects review changes, and how do those changes differ from something like Wikipedia?

One key cultural element of Wikipedia, at least so far in history, is that anyone’s edits to English Wikipedia immediately become part of the “live” version of the encyclopedia. By contrast, to maintain quality, open source projects typically permit only a handful of people to directly “merge” changes into the main project. Therefore, submitted changes go through review.

Different communities have different standards and processes. Sometimes, there is no review at all, just automatic merging by the maintainer. In other cases, like Linux, submissions go to a mailing list for review. Others, like the OpenHatch web app, use web-based tools like Github pull requests. A great reference for a more complicated process is the OpenStack Gerrit Workflow documentation page.

Python Petting by MTSOfan / BY-NC-SA

Are you a Python user group organizer or member? Do you want more people, and a more diverse set of people, to show up to your user group events? Email us at hello@openhatch.org! The Python Software Foundation and open source outreach nonprofit OpenHatch want to help.

As part of a six-month grant funded by the PSF, Asheesh Laroia (OpenHatch, BPW) will:

• check in with you and your user group,
• enable communication and cross-pollination between your user group and other user groups,
• answer your questions and brainstorm with you about making user group events more welcoming, exciting, and well-attended, and
• provide guidance, suggestions, and resources for running fun events designed for newcomers to the Python community.

Additionally, Asheesh will track the number of intro and diversity-focused events run in the Python community and the demographics of Python user group speakers–key metrics for the PSF’s Education and Outreach Committee. The goals for this grant are that over the next six months, at least six intro/diversity events happen and at least eight user groups see improved speaker diversity.

If you’re already on the group-organizers@python.org list, watch out for an email from Asheesh. If you run a Python user group of any kind, and aren’t there — join it! And you can always email us right now to work together on your user group: hello@openhatch.org.

Skimmer with baby by Wildlifeshoots / BY

Welcome to OpenHatch newsletter number 10.

Starting this month, as a way to indicate what we have in common, and to encourage organizers to have more conversations with each other, we’re inviting outreach events to flock together as OpenHatch-affiliated events. Read more about our first batch of affiliated events and the history that created the principles behind them. If you run a newcomer-friendly tech event, consider joining the flock!

We had a really fun and successful PyCon; read all about it (you can watch the Scaling Community Diversity Outreach talk there too!).

Infrequently Asked Questions:

At each Open Source Comes to Campus event, participants ask unique, thought-provoking questions. We decided to write down these questions and answer them more fully on our blog.

OpenHatch ran a workshop at UMass Amherst. 32 participants made contributions to HexBog, the OpenHatch website, JMonkey Engine, BitCoin, PsychoPy, K-9, and GNOME Shell.

We re-designed the Events mailing list info page; we think it’s now the snazziest, bootstrap-iest Mailman list info page in the world!

OSCON and Open Source Bridge talks by OpenHatchers

This summer in Portland, the community-run Open Source Bridge conference brings people together in June, and the enormous OSCON does the same in July.

At Open Source Bridge, we’ll be training the trainers and talking about quantitative community management. Check out the entire list of exciting talks, and especially the diversity in open source panel!

At OSCON, Asheesh is leading a session on Quantitative Community Management and also giving a technical talk on Scrapy. Benetech’s SocialCoding4Good will have a booth at the non-profit Pavilion, and Asheesh will be there as well. Stop by!

OpenHatchy but not OpenHatch things around the web

Women in Free Software & Culture in India online community launched.

On Mozilla Hacks blog, How to Spread The Word About Your Code does not cover (do we have a link?) how to make your project welcoming to new contributors, but it complements our advice nicely: if nobody ever hears of your project, there will be nobody to be feel welcome.

Nik Molnar blogs New Contributor? Jump In! encouraging open source projects to tag bugs that are good for new contributors; in comments many projects doing variations on this practice are noted, including one from Josh Matthews: “If you aren’t familiar with OpenHatch, I think you’re in for a deightful surprise.” We hope so! But it is also a delightful surprise to see independent invention and implementation of a great idea.

Valorie Zimmerman blogs Tea and cookies for your new team members on welcoming contributors to KDE projects.

Open Source Career Taster Days happened this month in London: “A series of three one day workshops for women returners aimed at raising awareness of Open Source development as a dual skillset or second career.”

Get involved

Read about our new affiliated events designation, and join our Events mailing list to think about how you can plan your own!

Read previous newsletters.

Like, follow @openhatch at identi.ca or Twitter.

This year’s PyCon biggest, best, OpenHatchiest one we’ve ever been to. I had the honor of leading a panel of successful diversity outreach stories. If you want to see how the Boston Python model of working within an existing Python user group is spreading around the country, watch four affiliated event organizers tell their story!

After the panel, we headed back to the expo floor for OpenHatch office hours at our booth.

This was OpenHatch’s second PyCon booth — we were on the exhibitor floor in 2012 as well. We gave almost two dozen T-shirts to donors, and we grew our announce list (where we send the monthly newsletter) by almost 50%! We also met Tariq, who invited us to run an Open Source Comes to Campus event in Amherst. With the PyCon team’s approval, we distributed over 2500 stickers to attendees in their attendee bags, leaving a few to hand out at the booth. (They were such a hit!)

Earlier in the week, I had the honor of being a part of the first PyCon Education Summit. Naomi Ceder, the event’s organizer, invited me to talk about how outreach events can find attendees and spread the word about the educational opportunties they entail. Through the summit’s hallway track, I talked with a community manager at a large online education website and shared some ideas on getting their students to work together on projects. I also learned about Software Carpentry’s increasing focus on evaluating their programs, through which I met the ever-enlightening Caitlyn Pickens.

I also had the pleasure of attending the Python User Groups birds of a feather (BoF) session. I listened as organizers shared their concerns: user groups often need help managing funds, want advice on great event types to run, and know to do more outreach but need some nudging in the right direction. The situation reminds me of all the college computer clubs whose leaders I met over my undergraduate career: we want to build great local communities with our limited time, so we focus on our members and forget to share what we’ve learned and listen to other groups’ leaders. We worked to get most of the attendees on the Python.org group-organizers mailing list — if you are excited about improving your local Python community, join that list!

All in all, PyCon 2013 was a great event, and OpenHatch is honored to be have been an OSS / Community Sponsor! We can’t wait til the next one. In 2011, I stood on a PyCon stage and talked about community diversity outreach; in 2012, Jessica and I did. In 2013, there were four affiliated events talking about their work. In 2014, let’s continue the trend and pack 8 people on a stage!

OpenHatch is a community of people who care about free software, diversity, and outreach. For years, we’ve hosted an active Events mailing list where organizers of free software outreach events, hackathons, project nights, and programming meetups have traded tips, personal stories, and strategies for bringing diversity and newcomer-friendliness to our communities. As a way to indicate what we have in common, and to encourage organizers to have more conversations with each other, we’re inviting outreach events to flock together as OpenHatch-affiliated events.

If you run a newcomer- or diversity-oriented outreach event, we’d love for you to join the Events list and introduce yourself! If you want to dive right into being an affiliated event, read our recommendations and sign up here. You’ll join the Chicago Python Workshop, RailsBridge Boston, PyStar Philly, the Boston Python Workshop, and others in a growing community. In the rest of this post, I’ll share some history and what has shaped my thinking about outreach events.

Testing ideas and helping them spread

In September 2010, I organized the first Open Source Comes to Campus event, held at Penn and pictured above. In many ways, it was great success; thirty undergraduate students, with healthy race and gender diversity, got together to learn how to get involved in open source. But the experience left me wondering how to sustain a long-lasting community, not just provide a flash of excitement. The experience of teaching, but not being sure if the attendees would follow up, reminded me of my experiences teaching at Noisebridge and at Hopkins.

Reflecting on this, I read about another successful outreach event, the RailsBridge Open Workshops in San Francisco. Inspired by their success at building diversity into the local Ruby Meetup, I asked if Karen Rustad (now an OpenHatch board member) if she wanted to attend a RailsBridge workshop and write about her experience. She did, and armed with her event notes, I assembled a team in Boston to try to clone it for the Python community there.

I wasn’t part of the Boston Python user group yet, so I joined and went to my first meeting. There, I shared my ideas and asked the organizer if we could make it a Boston Python event. He agreed! We found enough staff to make the workshop happen, and after the workshop, the organizers shared notes on what could make it work better next time. Since these outreach events are part of the main Boston Python user group, when our volunteers are tired, they can rest, assured that attendees can continue their learning through events in the Boston Python user group.

Over the past two years, the staff have put on seven intro workshop events, crafted a new Intermediate Workshop format, and blended into the main user group’s project nights (aka hack night) to make those events more newcomer-friendly. The event has helped attendees find community members and career opportunities by bringing them into the Boston Python user group.

When talking about the event at PyCon 2011, I met a great number of people excited about doing similar things in their home towns. Over the past two years, I’ve been honored to be able to answer questions from some of the organizers of those events. What has thrilled me is seeing those organizers form into a community. On the Events mailing list, people share information and experiences to help each other benefit and get the word out. And beyond the list, event organizers email privately, trade staff, and make friends.

Independent events with a shared commitment

RailsBridge Boston, the Boston Python Workshop, PyStar Philly, and other events share a commitment to diversity, outreach, and reflection. They’re run by independent groups of enthusiastic organizers. Like RailsBridge San Francisco that inspired us, they operate within existing communities, a strategy that helps their organizers avoid burn-out. They, along with the Chicago Python Workshop, the Columbus and Indianapolis and Dayton Python Workshops, are the first events to don the OpenHatch affiliated event moniker.

Together, we’re learning how to make our events better and better. On the mailing list, Marina shared her notes from the GNOME newcomers tutorial; Catherine Devlin showed us her new interactive Python learning framework on top of IPython, and Mako Hill wrote about evaluation metrics for Open Source Comes to Campus. Shauna analyzed sign-ups between two Open Source Comes to Campus events to find out if emailing attendees with a welcome note makes them more likely to attend. The organizers choose their own curricul and teaching tools, sharing notes so we can all benefit.

Together, we have a passion for measuring our successes and failures, reflecting on our events, helping each other set and achieve our goals, and doing great publicity to bring attendees to workshops and grow our communities.

You can join in

If you care about diversity and outreach, and want to run an event like this, you can get a head-start. Join our community by subscribing to the Events mailing list and introduce yourself. Read our recommendations and sign up, if you like, as an OpenHatch affiliated event. It’s a sign of your commitment to the ideals that have helped these events succeed, and a signifier that you’re interested in sharing notes, setting and measuring your goals, and willing to be mentored by other affiliated event organizers!

At each Open Source Comes to Campus event, participants ask unique, thought-provoking questions. We decided to write down these questions and answer them more fully on our blog. If you have any additional suggestions or advice, please add them in the comments!  

These questions are from our Wellesley College event. This post was co-written with Asheesh Laroia, with contributions by Paul Tagliamonte.

What is an integrated development environment, and why would you use it, and which one do you use?

An integrated development environment (IDE) is a program on your computer that does a lot of tasks which help you program. Typically it has an editor for writing text, a way to publish your changes through version control, and a way to run your program, which might include the ability to run your program through a compiler. IDEs might also provide syntax highlighting and auto-formatting, making it easier to read your code, and quick links to documentation. They might provide debugging tools like the ability to step through your code line by line and check the state of your variables and objects at any given time.

Whether you want to use an IDE depends on what features you find useful, and which you find cumbersome. Many programmers, as they become more familiar with the command line and with the various tools out there, find they prefer “just using a terminal and an editor”. For example, it can be easier to use Emacs or Nano to very quickly open, edit and close a file, whereas in an IDE one must typically create a “project” first. If they want to use a feature of an IDE, they can usually find some other way to get it. For instance, pdb is a tool for Python programmers which lets them step through their program line by line the way an IDE might. But a beginning programmer who’s not as comfortable juggling multiple tools might find it helpful to have them all bundled into one convenient package.

The type of project you’re working on will also influence whether you want to use an IDE. The Eclipse IDE is popular with Java and Android developers in large part because Java is a very verbose language. IDEs help programmers keep track of their work, and features like auto-complete can be a big time saver. On the other hand, if you’re doing web development, you might not need an IDE as browsers like Chrome and plug-ins like Firebug for Firefox provide a lot of development tools.

There are no obvious answers here. In the end, you’ll just have to see what tools are right for you and the project you’re working on.

How do you make time to contribute to open source when you’re a busy student?

By simply using open source programs, you are uniquely positioned to help other users. Don’t forget that helping people use the software is a substantial contribution to the community! By becoming an expert in whichever programs you use, you will also gain the knowledge to help convert bugs filed by others into actionable reports for the main developers. And once you reach that point, you might find it easier to just fix the issue!

That said, it can be daunting to add another activity to schedules already stuffed full of classes, paid work, and student life. One way to approach open source is to see it not as an alternative to doing schoolwork but as part of your education. For computer science majors, open source projects are a great way to practice the concepts you’re being taught in class. In the others sciences, learning how to use and contribute to open source tools such as R or Octave (or ImageJ or PsychoPy or JMARS) can help you excel when doing laboratory work – and looks great on your cv. Even in the arts and humanities, learning about open source tools such as Processing can help you succeed.

For students who work while they’re at school, open source projects can be potential employers. You can apply for Google Summer of Code or the GNOME Outreach Program and do a paid internship at an open source project. Individual companies working with open source may hire students that show enough interest and ability. You can even employ yourself using open source – for instance, doing freelance work making websites and apps using open source tools like WordPress and Drupal.

You can make open source a part of your social life as well. Make or join a Students For Free Culture chapter on your campus or invite friends over for a ‘bug-fixing party’. We promise you’ll be super popular.  🙂

Finally, remember that your contributions to open source can be as big or as small as you want them to be. If you only have time to spend a few hours a month writing documentation or fixing small bugs in a project, that’s great – the skills you’re learning and connections you’re making will serve you well if you ever decide to get more involved.

What open source music projects are out there?

Looking on Wikipedia finds a list of apps and categories of apps. Another great source of news about free software projects is freecode.com, where you can search for the keyword “music”. A great way to find open source projects that are actively-maintained is to search the list of Google Summer of Code mentoring organizations.

Often, the best way to find out which software project to contribute to is to find a program that you enjoy using. There is no substitute for running a program and using it for a while.

Here are a few particularly exciting programs that are worth mentioning:

• There are a few programs for editing music scores. TuxGuitar is a guitar tabulature editor, and it runs on Windows, Mac OS, and Linux. There is a call by a new community to test the latest code in svn and report back about its quality. Another, more full-featured project is MuseScore. Their community is very active, and they’re participating in Google Summer of Code.

• For rendering music scores, LilyPond is a well-known tool based on LaTeX.

• There are many music-playing programs, from Miro to Banshee to Rhythmbox to Amarok, just to name a few. If you run Ubuntu, you can find more in your “Software center”. Worth special mention are Zeya, which runs in the web browser, and Tomahawk, a very active project oriented around letting you listen to music from a variety of sources.

• You might be interested in specialized tools within the field of music, such as Echoprint for music identification, or Audiveris, for turning scanned printed music into digital files, or Audacity, for simple editing of sound files. Ardour is one of a few advanced open source audio mixing tools.

• If you’re interested in live audio programming, there’s a great library named Overtone. Overtone uses the SuperCollider engine, another open source audio project, written in its own language. A more recent project, Sebastian is similar to Overtone and implemented in Python.

The best way to search the space of the hundreds, or thousands, of open source projects in music is to find people using them and see what they say. Two great ways to do that include finding music communities and asking what tools they use, and reaching out to Reddit and posting in the open source sub-reddit to see what people recommend. You can also follow open source music blogs, watch videos on the topic, or check out cool groups like the Princeton Laptop Orchestra and see what tools they’re building and using.

What is the difference between source downloads for developers and downloads for users?  What’s a stable release?

Open source projects often release the program in a few different ways. Typically, if you are trying to contribute, you will want the latest source code cloned or “checked out” from the project’s version control system. If you are just trying to use the program, you typically want a user-oriented download.

May programs’ source code can’t be executed directly on a computer — they must be “compiled,” which turns it from human-readable text into machine-executable binary. The most common languages where this is true are Java, C, and C++. Therefore, the most useful download for a person who wants to run a project like OpenOffice, which is mostly written in C++, would be a compiled version specific to their operating system (for example, a Windows-specific build). By contrast, if you want to contribute to the program, you should act similarly to how the main developer acts — that is, by using a version control system on the editable program text, the source code.

Another important concept is the stable release. During development people make contributions that break the program, conflict with other changes, or are simply unfinished. At any given point the most recent version might be completely unusable. So maintainers periodically work towards releases (noun), which are tested to make sure they’re usable. If they are, maintainers release (verb) it.

So if you’re a user, you’ll want the stable release most appropriate to your operating system and computer. If you want to contribute, you’ll want the latest, non-compiled version.

Why are CS programs so theoretical?  Do they really help with practical programming work?

CS stands for computer science, which is an academic discipline about computation, data structures, algorithms, and many other mathematical concepts. It also covers how the computer works at a low level, typically by teaching computer architecture.

By contrast, being a professional programmer mostly involves writing code that connects other, existing pieces of code. It can seem like pure computer science would never come into the picture.

Most crucially, a CS program provides you homework assignments through which to gain experience programming and problem-solving tools that turn the infeasible into the feasible, as two examples show:

• When asked why your program is slow, you will be able to use theoretical tools like “big-O” notation and engineering tools like memory locality to comprehend why one program can run faster than another, even when doing the same task.

• When writing multiplayer game software, you might apply what you learned in an Internet Protocols class to understand why different players missed messages from each other.

CS concepts are very useful, but it is also true that you can write a great deal of software without knowing pure computer science. It is fair to say that the more general knowledge you have about computation, the wider variety of programs you can build.

Most professionals who have computer science degrees start their careers as “software engineers,” and the field of software engineering has tools and practices that enable people to build on top of other programs, or to share their code in a way that helps others to understand and review it. Those applied tools, like creating stable APIs or using version control, are in heavy use within open source development.

 Are all open source projects welcoming to newcomers?  How can you tell when the communities around a project are filled with jerks?

Not all open source projects are welcoming to newcomers. Not all open source projects need to be. Some projects benefit from keeping their communities small and experienced. And some maintainers simply don’t have the energy or the inclination to mentor new people.

There’s nothing wrong with that, but it’s a shame when newcomers try to get involved with a project that isn’t interested in involving them. It’s a frustrating experience for everyone, and unnecessary when there are plenty of people who’d be excited to work with them.

So how can you find a good project for you, a newcomer, to contribute to? Here are some good signs to look for:

• A large, active community is more likely to have members who can take the time to mentor. It also means that contributions will be acted on more quickly.

• Good documentation and demos mean that developers have thought about how to introduce people to their project.

• Some projects have Codes of Conduct/Diversity Statements, which demonstrate that the community is trying to be a safe and welcoming space.

• Projects that are part of Google Summer of Code or the GNOME Outreach Program have made a commitment to being good environments for newcomers.

At OpenHatch, we try to identify projects that are especially good for newcomers. We’re also developing a list of OpenHatch-affiliated projects that are working with us to make contributing to their projects as easy as possible. (If you’d like to be on that list, let us know!) Feel free to contact us and ask us for recommendations or if a particular project is known to be good for newcomers.

Of course, there’s a difference between not having the time and energy to help newcomers, and being actively mean or even abusive. If you experience the latter and our comfortable telling us about it, we’ll do our best to support you. OpenHatch people are always willing to provide advice on projects to join, either to help you find a great experience or to make the most of a bad experience. Find us on on IRC (#openhatch on irc.freenode.net) or ask hello@openhatch.org. You can also join groups such as Systers or the Empowermentors Collective, which may help you navigate the free software community.

By Asheesh Laroia / BY-SA

“When you appeal to people’s desire to make world better [software freedom] you get a different kind of contribution.” — Karen Sandler

Welcome to OpenHatch newsletter number 9.

OpenHatch ED Asheesh Laroia explains why we do what we do on his personal blog.

OpenHatch will be at Transparency Camp May 4-5 in Washington DC, to help open government-oriented open source projects build stronger communities.

Our biggest/littlest fan:

Justin King is eleven years old. He stood on a box to address a room mostly full of kids and parents — the podium was a bit too tall for him. He gave a whirlwind talk describing how anyone can get involved in open source at any age. He personally likes shell scripting and making short animations in Blender. He recommends asking questions, but reminds the young audience to never give out their phone number when contacting people on the internet. He also recommends OpenHatch as a resource for folks who are new to free and open source software.

On Saturday, April 6, our Open Source Comes to Campus For Women in Computing program visited Wellesley College.

On Thursday, April 11, OpenHatch presented at the Wikimedia Tech Meetup about Open Source Comes to Campus.

On Sunday, April 14, Open Source Comes to Campus visited UMass Amherst.

Dana Bauer has an excellent writeup of PyStar Philly, an affiliated event, celebrating five (and counting) Python workshops for women in Philadelphia — 140 graduates!

OpenHatchy but not OpenHatch things around the web

On the OpenHatch events list, Jennifer Mylo:

At WordPress, I’m just starting a new diversity workshop initiative (pilot planning) that is beginning with a focus on women, but is going to hit socioeconomic (with a splash of race) next, by trying to partner with less exclusive colleges as you suggest.

Luke W. Faraone on teaching free/open source to high school students:

The class was broken up into three segments: 1. Lecture on a brief history of open source and the free software movement 2. Small research project on an open source project 3. Lab where students could work through OpenHatch’s training missions

Marina Zhurakhinskaya writes about increasing participation of women in Free and Open Source Software , including the GNOME Foundation’s Outreach Program for Women. Also see video of a presentation by Karen Sandler on the same topics at the Linux Collaboration Summit (source of the quote at the top of the newsletter).

Get involved

This summer, you can help contribute to the OpenHatch web code through a Google-sponsored paid internship program. Check out our ideas page! Thanks to the Python Software Foundation for putting us under their umbrella. Pay attention to the deadlines and get in touch soon!

The photo at the top of this newsletter is of OH Google Summer of Code 2010 alum John Stumpo helping with Open Source Comes to Campus Johns Hopkins University last year. Get involved, stay involved!

Read previous newsletters.

Like, follow @openhatch at identi.ca or Twitter.

On Sunday, April 14th, we ran our ninth Open Source Comes to Campus event, at the University of Massachusetts-Amherst. Many thanks to Tariq Ahmad, Andy Yee, UMass IEEE and UMass ACM. Check out the photo gallery!

Schedule

• Introductions & laptop setup
• Intro to open source communications tools
• Version control demo
• Career panel, featuring Albert (Nexenta), Jason (consultant), Marina (RedHat), and Will (Mozilla)
• Lunch!
• Ethics & history of free software (shortened version)
• Github group demo
• Contributions workshop
• Wrap up

Staff

Asheesh Laroia, Shauna Gordon-McKeon, Marina Zhurakhinskaya, Owen Taylor, Jason Woofenden, Will Kahn-Greene, Albert Lee, R. David Murray

Contributions by students

• One attendee fixed a bug in HexBog, a browser-based word game maintained by staffer Jason Woofenden.  Together, they completed a long-standing wishlist bug to improve the animation that brings new tiles onto the board.  Now new tiles slide into view with lovely timing, instead of appearing suddenly and then sliding down a bit, as they did before.
• An attendee helped improve the OpenHatch website by making sure readers looking for more help with Git were directed to the correct IRC server.
• A group of five attendees took on a bug in jMonkeyEngine where the colors of a pair of axes needed to be switched.  They downloaded the software development kit, went through the beginner tutorial, followed the instructions for debugging, and even asked for help in the IRC channel, but were unable to find the axes in question, either in the running software or in the code where they were defined.  Despite these obstacles, the students seemed engaged, and swapped contact information so they could work together on the bug after the event.
• An attendee who’d asked to contribute to BitCoin was able to fix a file descriptor leak bug. He added an else statement to catch a condition, then worked with the project maintainers to make sure his commits were formatted correctly and efficiently.
• Another attendee spent some time improving demos for PsychoPy. The maintainers of PsychoPy have collaborated with OpenHatch to define a set of standards for project demos which multiple attendees have worked on over the course of several events. She chose to help standardize escaping, and plans to refine and submit this contribution after the event.
• A pair of attendees attempted to correct the behavior of a selection tool in K-9. They were able to replicate the bug and made some progress locating the problem code, but weren’t able to fix the issue.
• Three attendees collaborated to fix a bug in the GNOME shell where non-links were being misidentified as links.  Investigating and testing the bug required a copy of GNOME, so they worked with a staff member – one of the maintainers of the GNOME shell – to get a virtual machine on their Mac systems.  After figuring out how to reproduce the bug, they found the regular expression in the GNOME source code which was used to identify the links and figured out the appropriate change to it.  They worked through the difficulties posed by a new operating system, a large code base, and a 20 line regular expression to produce a patch, which has now been landed and will be in the next release of GNOME.

Errata

• Our hosts at UMass graciously invited students from other schools at the area. There was a strong showing from Mt. Holyoke college, who joined over twenty students from UMass. Students from Amherst College, Hampshire College, and Greenfield Community College also attended.
• For this event, we tried a new, more personalized email process which involved in depth conversation with potential attendees to find projects they were interested in working on. This process seems to have worked very well – while past events have had attendance rates as low as 25% of sign-ups, at this event 56% of sign ups attended. Over 80% of sign ups who responded to the personal emails attended. It also made for a more engaging workshop period, with over half of our 32 attendees staying until the end of the workshop.
• The only downside of having such a great showing was that lunch felt scattered and anonymous. Can we do more to help attendees socialize with each other and with us?
• We’re working to improve the way we find, curate, and display contribution opportunities (you can see the code for the version we used at this event here). Huge thanks to Nathan Yergler and Susan Tan for their profound contributions to that codebase, giving it the features we needed for the event!
• One of the day’s greatest success stories came when a staff member very familiar with a project helped a group of students work through a bug in it.  Over the summer we’ll be working on ways to create experiences like that for more of our students.  If you’re a maintainer of an open source project and would like to get involved, please let us know.

Transparency Camp 2012 by Burt Lum

TransparencyCamp is a yearly unconference to celebrate, and work toward, government transparency. It’s run by the Sunlight Foundation, and we’re honored to be a sponsor! Asheesh Laroia and I will be attending, and Sunlight Foundation has set aside a special area to help open government-oriented open source projects build stronger communities.

Open source and open goverment communities have always been peas in a pod – an opened pod, of course. The Sunlight Foundation’s many tools and applications are open source – from Checking Influence, which lets you see the political affiliations of the companies you exchange money with, to Capitol Words, which helps you visualize Congress’ most popular phrases, to Scout, a political notification service. You can contribute to the code. They also run Open States, a project which collects and organizes state-level legislative data – and which employs frequent OpenHatch volunteer Paul Tagliamonte.

Paul isn’t the only OpenHatcher with an interest in OpenGov. I’ve been organizing open government meetups in Boston, MA, for over two years, and had a blast at Transparency Camp last year. Board member Karen Rustad interned at open-source-oriented Code for America during summer 2011, working on a system to help cities leverage local open source communities. Asheesh has written code for an Electronic Frontier Foundation project around patent re-examination and has been active in e-voting transparency in the past.

Last year, the conference attracted more than 400 attendees from around the world and the U.S. Here’s what it was like:

Thanks to the event’s sponsors, Sunlight was able to provide a travel scholarship to lots lots of other attendees. Asheesh and I are honored to be a part of that.

If you can get out to the Washington, D.C., area on Sat May 4 – Sun May 5, you should sign up and attend! Hope to see you there!

On Saturday, April 6th, we ran our eighth Open Source Comes to Campus event, at Wellesley College. Many thanks to Kristian Tran and the Wellesley Department of Computer Science.

Schedule

• Introductions & laptop setup
• Ethics & history of free software
• Intro to open source communications tools
• Intro to version control
• Lunch!
• Github group demo
• Contributions workshop
• Wrap up

Contributions by students

• One attendee attempted to reproduce a four-year-old bug in WordPress’ redirect-processing logic. She couldn’t reproduce the issue and updated the ticket to say so. The same attendee also updated a bug in svg-edit, which reported that rectangles drawn while zoomed in were misplaced. While investigating the issue, she discovered that the direction and degree of misplacement were correlated with where the user attempted to place the rectangle on the canvas.
• We encouraged one attendee, who had an interest in musical composition, to browse around the bug trackers for various music-related open source projects. She found a seemingly straightforward bug in MuseScore where template files of the wrong length were being generated. Because she wasn’t searching by language, however, she found herself debugging a project written in C++, which she was unfamiliar with. She spent the rest of the afternoon learning basic C++ syntax as she looked through the code and read the documentation.
• Another attendee worked on patching the official Python documentation to mention that the `imp’ module was noted as being deprecated by the `importlib’ module. This change involved learning about how to produce a patch using mercurial, learning a bit about Python contribution guidelines and how to use the Python bug tracking system.
• Several attendees attempted this JMonkeyEngine bug, and by and large they ran into the same problem: that subversion does not come pre-installed on their Macs. The two attendees who stuck with the problem spent nearly half an hour downloading XCode, then familiarizing themselves with subversion. They also had to find where in the code the feature that was buggy was specified. By the time they located the problem, it was time to say goodbye.
• One attendee had a laptop running Windows, so she got to work looking into a GNOME issue where the main font does not render properly on Windows browsers. She found that while www.gnome.org had been fixed by adding Javascript to detect Windows and CSS to remove the special font on Windows, help.gnome.org had not been fixed. By testing in the browser, she confirmed that adding the same Javascript to help.gnome.org would fix the issue there. She left a comment on the bug, and we hope GNOME websites will now look better for visitors running Windows!

Errata

• We had very good retention throughout the workshop. Only one person left before the start of the contributions workshop at 2:30, and she was leaving for a preplanned event. During the workshop period, only three people left early, two of whom actively asked for follow up emails.
• During the version control tutorial we demonstrated the concept of version control by looking at host Wellesley College’s wikipedia page. Our attendees had a blast engaging in a minor edit battle. We’re adding this to our list of demos which lighten the atmosphere, along with the group git demo and logging onto IRC. (At this event, our attendees were so interested in IRC that they decided to create their own #Wellesley channel on Freenode!)
• People continue to love our t-shirts, which can occasionally be found on staff and volunteers. We should really bring extra to our events to give to attendees!
• At the end of the event, we tried a new format for wrapping up. We found it worked on a number of levels. It gave attendees who worked on a single bug all workshop a sense of the variety of possible contributions; it gave staff with relevant expertise a chance to offer help; and it let attendees celebrate their accomplishments. This is another change that we’ll be keeping.
• Attendees again expressed strong interest in follow up events. We’re hoping to make an alumni mailing list where students across OSCTC campuses can meet and network with each other. We’re also going to host a few informal project nights with alumni in Boston, and perhaps other areas where OpenHatch mentors are located.