On Sunday, September 22nd we ran our thirteenth Open Source Comes to Campus event, at Purdue University. Thanks to the Computer Science Women’s Network for hosting! Check out the photo gallery.

Staff
Lauren Stuart, Mel Chua, Ed Finkler, Shauna Gordon-McKeon, Asheesh Laroia

Selected Contributions

• A pair of students were interested in tackling bugs in Octave, a language for data manipulation, computation and visualization. Setting up a development environment in Windows, which both of the students were using, proved difficult – so they focused instead on setting up linux virtual machines on their computers.
• One advanced attendee, who had previously worked on BioPython, dived into the project and looked at two different bugs. She improved project documentation and contributed to a discussion about how to implement a new feature. She also contributed to MediaGoblin by creating a patch for a configuration error.
• When people picture themselves contributing to open source projects, they don’t usually see themselves testing other people’s patches, but it’s a very useful contribution.  One student confirmed that a patch worked and contributed to an ongoing discussion about what the final fix should be.
• Another attendee found that a bug in svg-edit had been fixed but not released, so that users were still having trouble.  He left a comment to this effect.
• One student worked remotely with a maintainer of PsychoPy to set up the development environment and become more familiar with the project.
• Another attendee worked on D3, a Javascript library for visualizing data, and submitted a patch to fix a documentation issue.
• A group of students tried to fix what seemed like a straightforward bug in Privly but had a lot of difficulty getting the development environment set up.  See the ‘Errata’ section for more on this.

Errata

• You can see the group who worked on the Privly bug in the photo at the top of the page.  Their description of the issues they encountered: “lots of downloads, need an approved account to have access… had to create own database on localhost… tears clouding vision”.  While they still had a great time, this experience made it clear to us that we need to do a much better job of picking projects to work on, and make sure that we’ve vetted the development environment setup process thoroughly.  Since the Purdue event we’ve focused on having a smaller number of high quality/highly prepped projects, and we think it’s showing major benefits.
• We had 25 attendees at the event, many of whom were non-CS majors thanks to our efforts to improve outreach to science majors. Part of that effort involves identifying and publicizing to potential attendees the many amazing open source science projects out there. You can help us with that.
• We introduced two major changes to our curriculum at this event:
  • A ‘Bug Comprehension’ activity where students pair up and read the issue tracker threads for two delightfully strange bugs: a problem with the Android calendar where the month of December was missing and a bug where Open Office doesn’t print on Tuesdays.
  • ‘Practicing Git’, a hands-on group activity where students practice forking and cloning repositories, making changes, and submitting pull requests by changing a toy project. You can see our student handout for the project and one of the repositories students worked on.

  We hope to have longer posts up soon which will elaborate on these curriculum changes and why we made them.

• To continue the trend of ‘recommended reading lists’ a few mentors and students got into a discussion on good readings for women in technology and science:
  • Unlocking the Clubhouse by Jane Margolis and Allan Fisher
  • The Madame Curie Complex by Julie Des Jardins
  • Reconfiguring the Firewall by Carol Burger, Elizabeth Creamer and Peggy Meszaros
• And to continue another trend: the phrase of this event was “rubber ducking” – the practice of asking your questions to a rubber duck or other inanimate object in the hopes that the process of clearly defining your question will help you answer it.

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 IU Bloomington event. This post was co-written with Asheesh Laroia, with contributions by Karen Rustad and Máirín Duffy.

Read on to learn more about building open source communities, diff and patch, open source design, and part-open/part-closed projects.

I’m worried that I’ll be a burden on a project because I’m so new. What kind of effort does a project have to make to build an open source community?

First of all, you should know that expert open source community builders like Linus Torvalds understand this tension between training new contributors and the time it takes from existing maintainers to mentor them. I’ll quote two paragraphs from a 2004 post Linus made on the Linux kernel list:

On Tue, 21 Dec 2004, Jesper Juhl wrote:

> Should I just stop attemting to make these trivial cleanups/fixes/whatever
> patches? are they more noice than gain? am I being a pain to more skilled
> people on lkml or can you all live with my, sometimes quite ignorant,
> patches?
> I do try to learn from the feedback I get, and I like to think that my
> patches are gradually getting a bit better, but if I’m more of a bother
> than a help I might as well stop.

[Linus replied:]

To me, the biggest thing with small patches is not necessarily the patch
itself. I think that much more important than the patch is the fact that
people get used to the notion that they can change the kernel – not just
on an intellectual level (“I understand that the GPL means that I have the
right to change my kernel”), but on a more practical level (“Hey, I did that small change”).

Another thing to keep in mind that is, for most projects, the project leader is the only contributor (source). Consider this — the act of “bugging” them with questions as a newcomer can make them more enthusiastic about the project as a whole!

If it were trivial to build an easily accessible open source community, virtually all projects would do it. There is some effort involved. Of course, a lot of the work which makes a project welcoming to newcomers – good documentation and setup guides, a well-maintained issue tracker, active development, standards of conduct in the community – makes the project better for everybody. But it does take time and energy, which many projects aren’t willing to expend. That’s why we exist! We know that some projects put more effort into welcoming contributors, and we want to help you find those projects.

The kinds of projects that welcome newcomers don’t see you as a burden. They see you as a huge help – even when you’re struggling to understand bugs in the issue tracker or get the development environment set up. When you ask a member of an open source project for help, that gives them important information about what part of their project is confusing or incorrect. The questions you ask and guidance you need lets them know how help others later on. And of course, once you’ve gotten familiar with the project, you’ll be able to help even more. The right kinds of project see that potential in you and want to work with you to get there.

Two rules of thumb for people who worry about being too much of a bother (which includes us, sometimes!): First, if people on the mailing list or the bug tracker haven’t told you to stop talking, then you’re probably okay, even if they haven’t replied to you yet. Second, if you want another opinion, just join the #openhatch IRC channel and ask us.

What are the flags for the patch and diff commands?  Why would you want to use them?

The quick answer is, “You always want diff -u, and you usually want patch -p1.”

The long answer is: The diff tool generates a text file summarizing the changes between some files. There a variety of formats that diff knows how to generate, and the default is an older format that isn’t widely used anymore. The most commonly used change format is “unified diff,” which is what “-u” specifies. My favorite (in its weirdness) is the “Ed script” format; you can read about that on Wikipedia.

As for patch, the most common command line flag to change is the number after “-p”. This helps patch choose which files on your computer to edit. Recall that the idea of diff+patch is that one person creates a file using the diff tool, and another person applies it on their computer with patch. In that case, what if the person creating the diff had placed the files in a different directory than you? Your use of the “-p” parameter controls that, and the “Levels in the Patch Command” section in How to create and use a patch in Linux explains more. Not everyone is excited about having to choose the right option; you can read Dustin Kirkland’s blog post where he wrote a tool to avoid having to ever pass this parameter in!

Like most UNIXy utilities, diff and patch have pages in the “manual”, which you can access by running man diff or man patch in your terminal. You can also read these online, for example at man.he.net.

How can I help open source projects with design?  Would I look in the bug tracker?

answer written by Máirín Duffy and Karen Rustad

You rarely find purely-design issues in bug trackers. Often you find a feature request which has an obvious design component, but the design and the development are lumped together in the same ticket. One approach, then, would be to make a new ticket for just the design, link it to the original ticket, and then assign that to yourself, which both communicates your intent and breaks the feature request up into more manageable chunks of work. But you may be better off looking specifically for projects that have design teams, as sometimes the design teams have ticket trackers with easy tickets designers can pick off, or a specific process for getting started as a designer.

It’s important to note the difference between a visual designer/artist and a UX designer/usability practitioner. Visual designers/artists usually find it easier to get involved – most projects need icons, logos, marketing materials or other artwork at some point. I [Karen] have had the best success just asking a project maintainer in IRC what design needs they have, or pointing out a design problem I’ve noticed and expressing an interest in fixing it, and chatting from there.

It’s harder to get involved as a UX designer or usability practitioner. Design is ‘controversial.’ (See the GNOME 3 design.) You always want the developers to have your back so it’s very important to cultivate a great relationship with them and be very willing to move on to another project if a project you’re interested in turns out not to be so interested in having a UX designer or usability person involved. The best luck I [Máirín] have had getting involved cold turkey, when I had no experience with the project or people involved, was to actually design something for them first, send it to them, and ask for feedback. If you get it wrong but it’s obvious from the work that you’ve got good chops then very likely they’ll start a healthy dialogue with you and bring you into the fold; but the risk is you never hear back and the work you put in doesn’t really go anywhere (into the upstream you intended it for at least).

What if you want to make only part of a project open source?

There are many reasons you might want to keep some parts of a project private.  Maybe your project deals with sensitive information and you currently store that private data alongside your code.  Maybe you’re a teacher and you don’t want students getting access to materials they’ll be tested on. Maybe you’re a company and financial success means waiting to make all of your work open source.  Maybe you’d like to wait until your work is more polished before you show it to the world (though this is a common trap that leads people to forget to ever share!).

Whatever your reason, generally the best way to proceed is to separate the open and private parts of the project into different repositories. There are several hosts that support both open and private repositories.  Some, such as Bitbucket, provide private repos for free (although only for five users or less), while others such as Github charge for them (although Github is currently providing private repositories for free to women through the Ada Initiative, and also a standing offer for students).  If the sensitive information is relatively limited, you may be able to keep it in a single file or folder outside of the version controlled repository where it is easily referenced.

If you need to keep information private for legal reasons, it’s important that you consult with whoever put those rules into place to make sure your chosen solution adequately protects the information.

You can read more about a part-open, part-closed strategy from people who have done it. “Open Source (Almost) Everything” is a seminal post on the topic, by Tom Preston-Warner, one of the founders of GitHub; you can also read posts decrying this “open core” model.

For Ada Lovelace Day this year, we decided to profile some of the women who have helped us organize and run our Open Source Comes to Campus events.  The five women below are just a few of the dozens of amazing hosts and mentors we’ve had the honor of working with.

Kristian Tran

Kristian invited OpenHatch to Wellesley College after hearing about us from Sumana Harihareswara, who gave a talk at Wellesley about women in open source last year.  She understood that open source sometimes has a steep learning curve and hoped that OpenHatch could help guide her and her fellow students through the first steps of that process.  Kristian, who also revived the Computer Science Club on her campus, is a great organizer and helped us get the event smoothly before settling down to take everything in as a student.  By the end of the day she had submitted a patch to the official Python documentation, which was accepted a few days later.

Kristian began programming during an introductory class her freshman year, and fell in love with it immediately.  According to Kristian, “Open source came into the picture after realizing that I’m utilizing all these languages and technologies for free and wanted to give back.”  She adds that it’s a great way to exercise computer science skills in a real world setting.

Kristian graduated from Wellesley last spring and joined Carbonite, Inc as an associate software engineer.  She hopes to eventually co-found her own technology company and to help inspire women to support each other when navigating careers in technology.

Molly White

Molly was one of the main hosts/organizers for our event at Northeastern University this summer.  Because the event was open to all students, Molly helped bring open source not just to NEU but to people from a dozen different schools.  In addition to organizing the event, Molly helped as a mentor during the event and joined our career panel to talk about her experiences doing Google Summer of Code.

Molly first got involved with open source at the age of 13, when she began editing Wikipedia. She started programming in late high school, and taking classes at NEU confirmed her interest in computer science. Naturally, her first open source contributions were to MediaWiki, the backend of Wikipedia, with whom she did Google Summer of Code.  Her advice to women getting started with open source?  “Don’t be afraid to ask for help. I was really shy about this when I first started programming and contributing patches, but I’ve had almost entirely positive experiences when I ask for help. I usually get really useful answers, and very rarely feel like people are judging me negatively for not knowing exactly how to do something.”

Molly continues as a student at Northeastern and as a volunteer contributor to MediaWiki. She’s also a research assistant with the Lazer Lab at Northeastern on a project to use data from Wikipedia and other sources for election prediction.

Mel Chua

Mel was one of the mentors for our recent Open Source Comes to Campus event at Purdue University.  This was hardly Mel’s first open source rodeo: she’s a PhD student in Engineering Education at Purdue, a two-time resident at Hacker School, and used to teach professors how to help their students get involved in open source.  That experience made her an excellent mentor not just to the students at the event, but to us.  Mel provided great feedback after the event, and helped us think through our goals and teaching methods.  We put her advice – and a new activity which she brainstormed with us – into action immediately.

She describes her own start in open source:  “I started by staring at my computer going ‘wow, Open Source is so cool.  I wish I could contribute to it.  But I’m not Good Enough yet.  I’d better go study more… then I might be Good Enough to help out.’  6 years and an engineering degree later, I realized this was an endless loop; there was no breakpoint criteria for ‘good enough’, so it would always be ‘better than I am right now, I’d better go and study more.’  At some point, there had to be a beginning, as messy and/or awkward as it might be.”

Mel recommends finding a mentor to help you get started in open source – someone who’s willing to “meet you where you’re at and get you to the point where you feel comfortable contributing independently.”  She believes that for most people, the community around a project is more important than the project itself, when you’re getting started.

Devina Dhawan

Devina was one of the lead organizers for our women-only event in Chicago last month. Along with several other members of the University of Illinois-Chicago Women in Computer Science (our hosts), student leaders at other schools, and women active in the Chicago open source community, she helped us pull off an amazing two-night event.  An experienced open source programmer, she helped out as a mentor and helped students from across the Chicago area feel welcome at the UIC event.

Devina was introduced to open source when she was 12 and her father brought home a Linux machine.  “It was amazing, the machine ran way faster than my emachines, so I used that all the time. Obviously all my teachers scolded me for not turning in a MS Word formatted document (so what else is new). The big push I had in my life for technology was my dad, he really guided me into a field he knew I would be perfect for.”

Devina continues to organize with WiCS.  For Ada Lovelace Day, she helped organize and is on a panel about about the Grace Hopper Celebration of Women in Computing (an event where we had the pleasure of seeing her again.)  She’s also planning her first steps towards a longtime dream of hers: building her own operating system.  We suspect she’ll be a success at whatever she puts her mind to, whether that’s putting together operating systems – or communities.

Elena Machkasova

Elena is perhaps the single biggest reason for our recent whirlwind tour, in which we visited three states, held five events, and reached over a hundred students from dozens of different schools.  Elena first heard about us at a Clojure meetup in Boston, and immediately contacted us, asking us to come to the small, public liberal arts college in Morris, Minnesota where she is a professor of Computer Science.  Over a year later, we finally made it out (stopping in Indiana and Illinois along the way.)  Thanks to the enthusiasm of Elena and other faculty and students, the Morris event was one of the smoothest, friendliest, most productive events we’ve had.

Elena has three pieces of advice for students entering open source:  “Build upon what you are good at and what you are interested in, and don’t be shy about contributing what you are good at.  Don’t avoid tasks that look scary or confusing, try them.  If it doesn’t work at first, ask someone for help.  Don’t get frustrated, new skills take time to develop.  And keep on learning: from sources, courses, mentors, etc. This field is developing incredibly fast, and it’s fascinating!”

Elena and her fellow faculty at Morris plan on keeping open source a part of their students’ education, both by running Open Source Comes to Campus-style events in the future and by incorporating open source into their curriculum.  Elena also incorporates open source into her poetry – such as this poem written in Clojure.

 *

Thanks so much to Kristian, Molly, Mel, Devina and Elena for agreeing to be profiled in this post.  Thanks also to the many other women who have participated in Open Source Comes to Campus over the last year as volunteers, organizers, mentors, and attendees.  One of the best things about working with OpenHatch has been getting to know so many brilliant, friendly, giving women in tech, and I hope to keep meeting you all, online and off.

Happy Ada Lovelace Day, everyone!

On Saturday, September 21st we ran our twelfth Open Source Comes to Campus event, at Indiana University – Bloomington.  Our thank yous to Dr. Lamara Warren and Lindsey Kuper of the School of Informatics and Computing for hosting!  Check out the photo gallery and out-takes.

Staff

Lindsey Kuper, Azadeh Nematzadeh, Suresh Marru, Larisse Voufo, Alex Rudnick, Dian Y, Beenish C, Molly R, Nathaniel H, Aaron H, Shauna Gordon-McKeon, Asheesh Laroia

 Selected Contributions

• We had several students attempt to work on PsychoPy, a stimulus presentation package for psychology.  Unfortunately setting up the development environment for this project is arduous, especially on Windows.  Despite the fact that none of the students got set up in time to work on any of the issues, they were enthusiastic about working with the project maintainers to improve and document the setup process.  Over the next few weeks we’ll be working with those five students, and with PsychoPy’s friendly maintainers, to do so.

• One student spent some time learning about OpenStates, going through the codebase with a mentor and understanding how web scraping works.  She attempted to respond to a feature request – adding some code that pulled in committee votes to the Pennsylvania scraper – but discovered that the feature had already been added.  The project has piqued her interest, though, and she’ll be working with OpenStates’ maintainers on a yet-to-be-determined issue.

• That same student reported an issue with our tasks tracker which we’re hoping to fix soon.

• One attendee tackled a bug in BioPython, and was able to come up with a fix to help a program deal with an error gracefully, but wasn’t able to test his changes, as the person who reported the issue wasn’t able to provide the input to reproduce it.

• Another student submitted a patch for a problem in gnome-applets where strings weren’t getting translated properly.

• One student attempted to fix a problem with the layout in the Privly project website but difficulty with her internet connection meant she wasn’t able to work much on it, and was forced to socialize with students and mentors instead.  This was much more successful, if you view having to deal with our puns on IRC as a success.  We look forward to seeing her next week at Grace Hopper.

Errata

• This event kicked off a week with 4 Open Source Comes to Campus events in 3 states, with over 100 attendees.

• We had 28 students at this event, with roughly equal numbers of men and women throughout the day.  We accomplished this gender diversity primarily by doing targeted outreach and by sending personalized emails to the women who signed up.  This enabled us to talk more deeply with them about their interests, and to encourage them to come.

• During the career panel, a discussion emerged about the sociology of the free software movement.  Some of the recommended reading (all free to read/download):

  • Coding Freedom by Biella Coleman

  • The Cathedral and the Bazaar by Eric S Raymond

  • Dispatches from the Revolution by Alex Skud Bayley

  • The Cost of Collaboration in Code and Art by Benjamin Mako Hill and Andrés Monroy-Hernández

  Feel free to recommend more in the comments!

• The phrase of the event was “yak-shaving” – the experience of needing to do one thing in order to accomplish another, recursively, until suddenly you find yourself shaving a yak in order to install subversion.  Especially relevant when setting up a development environment!  Assuring attendees that it’s not just them is one of the most vital things we do.

@hardy101 & @alexjarv1s burning the daylight fixing #wordpress #bug with @UMM_CSci students for @openhatch by Dan Flies

Welcome to OpenHatch newsletter number 14.

Open source came to four different campuses in the last two weeks of September! Around a hundred students from over a dozen schools attended events hosted by IU-Bloomington, Purdue, UI-Chicago, and UMN-Morris. More pictures, and blog posts about the events will be coming soon.

If you want OpenHatch to come to your campus, visit campus.openhatch.org and get in touch.

OpenHatchy but not OpenHatch things around the web

Two bits from an article on a developer panel at LinuxCon:

Sharp got a round of applause when she said she hopes for a more welcoming environment to newcomers. “I’d like to make sure our community is inclusive to all people that want to contribute,” she said. “Getting more diversity, getting more diverse voices in our community is something I’d like to see.” Earlier in the discussion, panel members talked about some programs designed to mentor new developers, including one program specifically for women. They’d like new developers to become frequent contributors instead of just contributing one patch before stopping.

Indeed.

Although kernel development can be intimidating because of how big and complicated the project is, Kroah-Hartman noted that recently a professor in the Czech Republic required a classroom of students to get patches merged into the kernel. A few of them liked the process so much they said they’d keep contributing, he said.

Excellent! If anyone knows of information online about this class, we’ll link to it in a future post. This professor’s method reminds of courses that assign contributing to Wikipedia. Introducing students to contributing to open collaborative projects, code and otherwise, in a structured class setting could be a great way to enable much more diverse participation.

Haskell Symposium program chair report:

First, it’s high time we learned from those people who did not find the Haskell community a welcoming place. If you were excluded, or if you know someone who was, please share your stories. Of course you don’t have any obligation to do anything, but out of the goodness of your hearts, please be our teacher. Please contact me, at ccshan@indiana.edu. I’m getting help from some cultural anthropologists at Indiana University. If you know about anthropology at Indiana, you’ll know that these are professionals who really know how to learn from and respect your individual experiences and perspectives. We’re going to conduct interviews and anonymize them. Then, I’m not sure what we’ll do with the interviews — maybe they’ll become a SIGPLAN Notices article, or a theatrical play, or a shared resource if the interviewees are willing. In any case, the goal is to strengthen our empathy for each other, to understand our different perspectives on our shared community, and to open conversations about this important topic.

Quim Gil:

The current round of Google Summer of Code & FLOSS Outreach Program for
Women is about to end, and it’s time to start a new cycle of mentored projects in Wikimedia tech.

David Pollak on the Strange Loop conference:

Supporting women in tech is an important goal for me. It wasmost impressed by Alex Miller‘s success in recruiting women presenters (yes, each letter is a separate link to a separate presentation) as well as DevChix.

I graduated law school in 1991 and my class was > 40% women. I’ve seenhow the women from law classes in the early 90s have improved theway lawyering is delivered because more smart, engaged people leads to better results. In tech, we are at the beginning of the processand the way that Alex Miller is enhancing the tech world bymaking women an integral part of Strange Loop deserves my highestpraise and thanks!

CIO.com article Open Source Career Opportunities Continue to Abound:

Whatever industry you’re in, if you’re an open source developer, it seems the market’s wide open. “Open source is everywhere, and we don’t see this market slowing down any time soon,” says Goli.

Not the typical OpenHatchy link, but the implication is clear: diversity in open source communities is not only crucial to the health of those communities, but to the computing industry, economy, and sociey at large.

Also check out links submitted to /r/openhatch, and add your finds!

Get involved

You can help write this newsletter! The October newsletter will be edited at htmlpad may be previewed there as well. Join our publicity list or hop on #openhatch with suggestions and questions.

Read previous newsletters.

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

College Hall pillars – Wellesley College by Daderot / public domain

Welcome to OpenHatch newsletter number 13.

Thanking our Open Source Comes to Campus sponsors for the past year:

OpenHatch is lucky to be supported by organizations and people who believe in our mission of growing the open source community through active outreach. We’re taking this moment, halfway into the year, to share our gratitude for the companies that have made that work possible.

These companies include Puppet Labs, Stripe, 10gen, Google, OmniTI, Dreamwidth Studios, Rackspace, Kitware, and Nokia. Please help more join them! See our sponsor prospectus, and send an email to hello@openhatch.org!

New projects in the OpenHatch volunteer opportunity finder

We’re constantly adding new projects to our volunteer opportunity finder. Two recent additions:

• CityGenerator, “a tool for generating a setting for Fantasy Roleplaying games”, links to a wonderfully detailed list of ways to contribute for both developers and non-developers.
• MCServer, an open source Minecraft server with “better performance than vanilla”, would love some help updating its wiki. Here is also an interesting Reddit thread with suggestions for inviting new contributors to that project.

Behind the scenes

On August 8, we had a release planning meeting led by IShadowed on IRC, discussing some development goals for the month. Here are minutes from that meeting. If you’re interested in helping, we’ll announce the next meeting on the devel mailing list (and quiet lurkers are also welcome to join and listen in on meetings).

New mailing list for detailed Open Source Comes to Campus event planning, which was previously done mostly via private emails. Our events list is still the go-to place for discussing and sharing lessons and questions on running outreach events!

OpenHatchy but not OpenHatch things around the web

“18% of attendees and 21% of speakers at #GUADEC are women! We are working hard to extend the openness of our community to more people.“

So, You Want to Run a Young Coders Class? by Katie Cunningham has lots of great detail on doing just that, pointed out by Sumana Harihareswara.

Read several good links submitted to /r/openhatch and submit OpenHatchy links you find. One just submitted: Interview with Alex “Skud” Bayley, founder of Growstuff and social justice activist:

If technology is going to change the world for the better, it has to involve all kinds of people. That doesn’t happen by accident. You have to work at it.

Also, thanks to the moderators of /r/opensource for adding OpenHatch to the sidebar of that popular reddit.

Get involved

You can help write this newsletter! The September newsletter will be edited at htmlpad may be previewed there as well. Join our publicity list or hop on #openhatch with suggestions and questions.

Thanks to Britta Gustafson for contributing to this edition!

Read previous newsletters.

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

Vaumarcus Castle at Swissminiatur, Switzerland by Andres Passwirth / BY-SA

Welcome to OpenHatch newsletter number 12.

Thoughts after our Open Source comes to City College of San Francisco event: Making Open Source Comes to Campus even more hands-on.

Asheesh Laroia will give a talk at Debconf on How other FLOSS communities mentor and what it means for Debian as part of the community outreach track. You can also check out the slides from Asheesh’s OSCON talks, one on scrapy and another entitled Quantitative Community Management.

At OSCON, Britta Gustafson joined the team of people answering emails to hello@openhatch.org, and independently, Courtney Thurston submitted her first pull request (which was merged and deployed). Welcome to both of them!

Through Google Summer of Code, Tarashish Mistra is working on making the training missions easier to edit on the web. You can track his progress on his GSoC blog. David Lu also joins us this summer to create new mentor-mentee tracking tools. You can read more on the Greenhouse project website and his GSoC blog.

You can help write this newsletter (see “Get Involved” below). Or if submitting links is your thing, submit away at /r/OpenHatch.

OpenHatchy but not OpenHatch things around the web

GUADEC 2013, August 1-4 in Brno, includes five sessions directly concerning outreach and welcoming newcomers.

Akademy 2013 happened earlier this month and featured a talk on welcoming newcomers in India and lightning talks by participants in summer programs, including the Outreach Program for Women.

Outreach Program for Women has a new site. The program has 37 participants this northern summer.

John Riedl died of cancer recently. The Wikimedia blog has a remembrance that includes links to his research on diversity and open collaboration.

Fiona Cullinan writes up a negative result in Female programming dream that’s gone off the Rails:

If I learned anything that day it’s the truth of ‘those who can do, can’t necessarily teach’ and the expectation the event engendered of beginners being able to code in a day left me feeling bruised. I came out upset and unsure of whether to continue – which is the very opposite of the outcomes those running the event were trying to achieve.

(Folks who can do, and want to teach beginners, join the OpenHatch events list and we can help each other avoid common pitfalls and improve together when they occur.)

If contributing to a project for a first-time contributor to open source is difficult, it’ll often also be difficult for a long-time contributor to open source but first-time contributor to the project. Karl Fogel writes about a technial barrier to first-time contribution that deterred him years ago, and joy at seeing a project fix that: Credit where credit is due: LibreOffice is now ridiculously easy to build.

Documentation is another great way to make free software better; to get intensively involved, check out the 2013 Doc Camp Call for Proposals.

Get involved

You can help write this newsletter! The August newsletter will be edited at htmlpad may be previewed there as well. Join our publicity list or hop on #openhatch with suggestions and questions.

Read previous newsletters.

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

Group of California Poppy by photogirl7.1 / BY-SA

OpenHatch is lucky to be supported by organizations and people who believe in our mission of growing the open source community through active outreach. We’re taking this moment, halfway into the year, to share our gratitude for the companies that have made that work possible.

In the first half of 2013, we’ve run five open source comes to campus events. We’ve visited women in CS groups at Wellesley College and Harvard University, and we’ve organized workshops with diverse attendees with the University of Massachusetts at Amherst, Northeastern University, and the City College of San Francisco to teach students what open source software is and how they can get involved.

On a personal note, it is a pleasure to have the chance to run events like this. The future of free software depends on participation from many more people. We’ve found students are hungry to learn how to get involved, how open source participation can be a part of their current and future careers, and to grasp the political aims of the free software movement.

With the support of these organizations, we’ve been able to focus on running and improving these events. By way of history, we ran six events in 2010, 2011, and 2012 combined, so five in the first half of 2013 means almost half of our events were this year! We’ve been polishing and publishing a growing body of resources that help us document how the workshops are run, and we used that as part of a training the trainers session at Open Source Bridge last month.

Thank you to the following sponsors who have supported the program in the past year (July 2012 to July 2013)!

Open Source Comes to Campus for Women in Computing, 2013: Bronze

Puppet Labs is the most generous sponsor, giving to help us run an event in Portland, OR, and to support the whole Open Source Comes to Campus series with its focus on women in computing.

Open Source Comes to Campus for Women in Computing, 2013: Patron

Stripe and 10gen also gave generously to make the year’s workshops happen.

Organizational sponsors, 2013

Google Open Source Programs Office and an anonymous individual donor gave generously to support the organization as a whole, making our work possible.

Open Source Comes to Campus individual event sponsors, 2012-2013

OmniTI, Dreamwidth Studios, Rackspace, Kitware, and Nokia supported individual events in our 2012-2013 series. The support of these companies help us make the events great and keep the program running.

Your name here!

We’re putting together a program for the fall semester that will bring workshops to more colleges around the country. We need your support! Can your employer or organization contribute to our vision of a generation of students, women especially, empowered to contribute to open source software? See our sponsor prospectus to see how to get involved, and send an email to hello@openhatch.org!

Gibbs Street Ped Bridge with Portland Aerial Tram cabin above by Steve Morgan / BY-SA

Welcome to OpenHatch newsletter number 11.

PSF funds OpenHatch to reach out to and help Python user groups:

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.

Our 10th Open Source Comes to Campus event was held June 22nd at Northeastern University:

Thanks to our our Northeastern hosts, who opened their doors to area students, we had sign ups from almost a dozen additional schools, including: Boston University, UMass Boston, Wellesley, Harvard, MIT, Brandeis, Babson, Mt Holyoke, Colby and even students from CSU-Sacramento and Valencia College in Florida.

July 29 OSCtC will be at City College of San Francisco.

Another set of very interesting but Infrequently Asked Questions, these from UMass Amherst Open Source Comes to Campus.

Our Executive Director Asheesh Laroia gave multiple talkes at Open Source Bridge earlier this month. See his speaker’s page for a list, and materials from previous years.

OpenHatch’s Shauna Gordon-McKeon and Karen Rustad attended AdaCamp, a two-day unconference for women in open technology and culture. Shauna attended with the help of a travel scholarship graciously provided by the Ada Initiative. She led a workshop on contributing to open source projects, attended sessions on open science, open government, and teaching open source, and generally had a blast meeting tons of smart, passionate women involved in open culture.

In July at OSCON Asheesh Laroia will be giving a talk on quantitative community management, and another on web scraping.

OpenHatchy but not OpenHatch things around the web

Sarah Sharp updates on the Outreach Program for Women Linux Kernel Internships:

A month ago, Amanda McPherson and Greg Kroah-Hartman from the Linux Foundation asked me to coordinate an internship program aimed at getting more women to participate in the Linux kernel. In order to be considered for an internship, the applicants need to submit patches to the Linux kernel, and get them accepted. The results have been amazing: 41 women applied for 6 Linux kernel internships. In 13 days, 374 patches were submitted, and 137 patches were accepted.

Emily O’Leary on Inclusivity in Free Software, with good examples to follow.

Applications for 2014 Code for America Fellowships are due July 31. A great opportunity to learn and teach about open source in government.

Get involved

You can help write this newsletter! The July newsletter will be edited at htmlpad may be previewed there as well. Join our publicity list or hop on #openhatch with suggestions and questions.

Read previous newsletters.

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

On Saturday, June 22nd we ran our tenth Open Source Comes to Campus event, at Northeastern University. Many thanks to Ali Ukani and the Northeastern University ACM for hosting.

Staff

Shauna Gordon-McKeon, Ingrid Cheung, Paul Tagliamonte, and Brendan McLoughlin; plus student staffers Molly White, Alice Young, Spencer Florence, Richard Van Buren, and Jonathan Goodwin.

Selected Contributions

• One student fixed a bug in NLTK where a failure to test all cases had led to a divide by zero error. The student figured out which case was missing and added a line of code to the problem function to fix it. Her patch was accepted a few days later.
• Two students worked together on a “stale” pull request in PsychoPy. They weren’t able to address the main problem, which involved vectorizing code, but they went through the process of refreshing the patch, and also learned how to use several different merge tools along the way. Another student working on PsychoPy cleaned up the imports in two different files. Both changes were merged into the project.
• One student confirmed a bug in multiple versions and updated the issue to share that information.
• A student working on K-9 mail was able to reproduce and clarify a problem with opening .apk files in the application. Another student attempted to address a different bug in K-9, an off-by-one error in folder selection, but ended up focusing on getting the Android development environment set up properly.
• One student addressed an issue with Wikimedia’s Bugzilla configuration where an error in the .css file was causing a random bullet point image to show on various pages. She fixed the code and submitted a patch, which was later accepted.

Errata

• Thanks to our our Northeastern hosts, who opened their doors to area students, we had sign ups from almost a dozen additional schools, including: Boston University, UMass Boston, Wellesley, Harvard, MIT, Brandeis, Babson, Mt Holyoke, Colby and even students from CSU-Sacramento and Valencia College in Florida.
• We mixed the career panel up this time, and included more discussion about part time and temporary paid opportunities. We had participants from Code for America, Hacker School, and Google Summer of Code (a student, and a mentor) talk about their experiences. We also asked a few new questions that seemed to really spark discussion, including: what are the financial models of the companies you’ve worked for and the projects you’ve worked for?  What was a time you were hesitant or frustrated about something in open source?  What projects would you especially recommend to newcomers? The panel seemed more lively than usual, and attendees more engaged.
• I don’t think we will ever stop learning things about event planning. Added to the checklist this time: make sure the room you’re in has heat in the winter and air conditioning in the summer. We sweated our way through the day.
• There was a brief conversation among the staff about modeling confusion, ignorance, and failure. The git demo, usually one of the smoothest and most enjoyable parts of the day, included an extra 5-10 minutes of rebasing and apologizing because the instructor had forgotten to tell students to start a new branch before making changes. I thought it was great! We believe it’s helpful for students to see instructors mess up, try again, and succeed. In a conversation shortly after, when a student expressed frustration with git, I was able to say, “It’s a hard skill to learn. You saw [the instructor] – even he doesn’t have it mastered yet!”
• During this event, we introduced pen-and-paper bug report worksheets (available in our resources). Our goals were multifold. First, we thought that listing out the steps for fixing a bug would help students walk through them. Some students express disappointment if they don’t make it all the way to submitting a patch, but this method highlights the steps they do achieve. Second, it provides staff with a visual clue as to who needs help and who doesn’t. A student with a blank form and no steps checked off is more likely to be struggling than one who’s writing away. And third, it lets us as organizers determine what kind of bugs are working for students and where they’re running into problems. As we continue our efforts to curate the best first contributions for students, that information is invaluable.