Talk transcript: Making your first open-source contribution

Slides available on SlideShare (I need to fix an embedding bug on the blog, oops).

Most of you know what Open Source Software is and hopefully think it's awesome. Have you ever contributed a patch? A translation? A bug report? Would you like to do any of this?

(If this is the first time you hear the term, roughly open-source is software for which the source code is freely available, that can be redistributed and modified.)

This talk is for people who like open-source and would like to give back, but are not sure where to start, or if they're smart enough or if their skills would be valued.

And my goal is to encourage you to make the jump from 0 to 1 contribution (or one more!) :)

Because I'm a software developer, this talk focuses a bit more on code contributions. (Don't think this means other types of contributions aren't needed, help is always welcome everywhere!) For many years, I wasn't strongly attached to any particular project but got patches in here and there (Sugar, Gnome, Django...) Nowadays you're more likely to find me in the land of OpenStack.

First, let's clarify something important: you don't need to be a genius to contribute. It's not as difficult as it may initially appear. All skill levels and all types of skills are needed and appreciated.

As to where to start, first I'm going to tell you about a wonderful shortcut, and then I'll go through how it usually works.

OpenHatch is an organisation whose mission statement is: "helping newcomers find their way into free software projects." They aim to bring together all the simple bugs, help requests and help wanted, documentation, all sorted by project and by language. It's a great way to get started.

Now, the way it usually works. When you're looking to contribute to a project, you should first look around for contributor guidelines. If a project has contributor guidelines, it's an excellent sign. It means that they care and that they've thought about it, which is very important when it comes to first contributions.

Read them! You don't have to remember it all. It will give you a sense of direction and an idea of what matters for the project, what to watch out for too (patch format, coding conventions, where/who to talk to, etc.)

As an example, here's a screenshot of the Gnome documentation for new contributors. There's a lot in there! They care a lot about welcoming new people.

In any case, whether a project has contributor guidelines or not, the workflow tends to be the same. Read the guidelines if they exist :) From then on, look at the bug tracker to find something that you'd be interested in working on. Now that you know which part of the project you will be working on, build it. Find the bug, fix it and submit your patch!

I'm going to be using the first contribution I made to Gnome as an example throughout this presentation. The Gnome folks are a very friendly community, and have a special tags for bugs that are good for newcomers called "gnome-love". In other projects this may be called "easy picking", "bite-sized", "low hanging fruit", etc... It should be mentioned in the contributor guidelines.

Look at the list of bugs tagged with that keyword and find one you like that is easy. (Avoid choosing a big feature as a first contribution. You need to earn some trust first, as well as pick up the project technical and cultural conventions.)

Once you know what you will be working on, it's time to build the software. This is very important, you will be learning new tools, perhaps even new languages. For instance I chose a bug from gnome-terminal which is written in C and uses autotools, which I wasn't very familiar with. This is why it's important to select a small first bug, because you have a lot more to learn to get there.

If you can't find instructions to build the software, you have a couple of solutions. Sometimes a mentor comes together with the "easy pickings" tag, or the community has its own mentorship program. You can also go back to the magical portal mentioned earlier, OpenHatch, where "training missions" are available to get people up to speed with some of tools commonly used in open-source.

People forget they had to learn all this in the first place. Don't sweat it. This is a stepping stone.

Once you have a working build, it's time to reproduce the bug, find it and fix it! If you're lucky, the location of the bug may have been mentioned in the bug report. As said earlier, the person who marked the bug as an easy task may be willing to help mentor you through it. It's ok to ask for help if you're having trouble.

As an example of a first task, I was lucky, and I indeed picked a very simple one - changing a colour in the gnome terminal!

Once your fix is ready and tested (you have rebuilt the software with your fix in it), it's time to submit the patch. Now is a good time to refer yourselves to the contributor guidelines once again, it will be useful to find out what your patch should look like (coding guidelines), what command you should use to create the patch, and where you should send it. If there are no such instructions, the safest path is to attach the patch to the bug report in the tracker.

And... congratulations! You've made your first contribution to open-source. Take the time to pat yourself in the back and be proud, you deserve it.

The process isn't quite finished yet: the next step is to wait. Perhaps your patch will be accepted since it's a small contribution. It's just as likely you might get some feedback on how to improve it - everybody wants to make their project better so don't take it personally, take the feedback on-board and resubmit the patch. If your patch gets lost in the ether, you should consider pinging the component or project maintainer.

In my case... I was lucky :) The patch was accepted and merged in the main codebase about an hour later!

If the only answer you get is silence - don't take it personally, really. People want you to stay, a healthy project know they need new people in order to stay alive. Open-source projects are always short in resources.

If the people involved in the project you contributed to have a bad attitude, don't be discouraged. And don't stick around either, there are a ton of cool, useful projects with friendly communities who could use your contributions. Life's too short.

If you've done your research, read the guidelines, there won't be any dragons. Most people are very nice! It's great to become part of a community that cares about creating the most awesome project they can.

And as a closing word before opening for questions: remember OpenHatch.org. They are people dedicated to helping newcomers find their way.

Leave a comment | 5 so far

"Making your First Open-Source Contribution" Ireland Girl Geek Dinners

Hello good people who attended my talk on "making your first open-source contribution" for the January edition of the Girl Geek Dinners in Dublin. I hope you enjoyed it!

The slides are available on Slideshare - this version is actually missing a couple of recent updates, the main one being the mention of the Open-Source Night starting in Tog on Wednesday, February 20th. Come make your first contribution or help others get there!

If you're looking for a copy of the hand-out, you can download it here.

I'll be posting a transcript of the talk in the next couple of days. It still needs a bit of proof-reading :-)

Many thanks to Christina for organising GGD!

Picture of the talk
(Thanks to @Imisaninja for the picture)

Leave a comment

Interested in open-source? Come to Tog!

Are you an experienced open-source contributor interested in recruiting new people for your project?

Are you a fan of open-source who would be interested in contributing at any level but isn't sure how to?

Come to Tog's first Open-Source Night on February 20th!

These hands-on sessions aim to bring together experienced open-source contributors with people who would like to get started but aren’t sure where to start or would generally benefit from having someone to ask questions to.
[...]
Every month we will start with a couple of people speaking for 5-10 minutes, to introduce the project they are working on, what is the usual path for contributing and where they are currently looking for help. Then we will form groups and work on making a contribution for the rest of the evening.


I'm hoping to make this into a regular monthly event. The current plan is to try it for a few months and see what it becomes. This will heavily depends on who attends so, help me recruit lots of interested people from both side of the contributor spectrum in Dublin :)

Leave a comment

Friendliness in open-source

The general view of open-source communities when standing at the edges is probably a vision of endless flames, strong personalities clashing, patches being ripped to shreds on mailing-lists, RTFMs, and the general need to have a thick skin when going in there or being crushed to pieces. The high-profile projects where one might think to contribute first like the Linux Kernel can have quite an intimidating culture, keeping lurkers looking out from stepping in.

I rarely read stories about the really friendly projects that do their best to mentor newcomers.

I'm currently mentoring for the OpenStack project as part of the Gnome Outreach Program for Women. Everyone I see talking to the interns, whether or not they're directly involved with or even aware of OPW, is helpful and makes the time to be friendly and answer questions ; what they see is new contributors interested in helping out and it's in their own interest and the project's to give a hand at the start, when it is most needed.

If you like open-source and sometimes think you'd like to contribute if you could: explore the community for the project(s) you're interested in. Most of them are really nice places to be. Have a look. Ask someone on IRC or on a mailing list for where to find directions on how to get started. Healthy communities are concerned about being welcoming and attracting new blood, because they know they need it to survive and be sustainable.

And if you're still hesitant about jumping in and have a specific question I might be able to help with, get in touch :)

Leave a comment

Python meet-up, November 2012: DevOps 101 DevOps 101

Shame on me for not blogging about PyCon Ireland this year, another success where I happily spent a big chunk of time greeting attendees at the registration desk and attended some interesting talks.

The stylish volunteers:

PyCon Ireland 2012 Volunteers

In the meantime, I took better notes at the November Python Ireland meet-up, where Ulrich took us through DevOps 101, going from the basics of what it is and all sort of related tools to help, mostly Python-based.

I thought interesting that Ulrich worked from a specific definition of DevOps that differs from the ones I heard. There was a time when I used to call myself "a devop" because in addition to development work I was also maintaining production and test servers and handling deployments, etc. However at the time I learnt from other sources that "a devop" was actually a system admin who also writes code to make their job easier... so I just stopped using the word ;) Ulrich based his talk on the premise  of development and operations working together.

Development tends to move fast while operations are more stable and conservative, why would you put these groups together?

The need to scale is an important one. You need the knowledge that the developers have of the application itself, but you also need to understand infrastructure. For instance if you deploy something and suddenly the number of requests spikes, you want devs and ops to be close together to solve the problem.

Following a "release early, release often" principle where you might deploy several times a day makes that collaboration important.

Environments are complicated and it's important for people to integrate ; if the departments remain separate people tend to stick only with the same group of people.

Devops enable better communication and understanding. Developers can move fast and deploy faster as they know what ops need. This also helps mitigate risk thanks to the regular deployments: fewer changes are deployed at once (helpful to determine what breaks) and it becomes easier to do.

The talk then moved on to tools, including advice on how to create a simple django app to keep track of which versions of software are deployed where -- very simple and yet usually enough.

Some of the projects that were mentioned:

  • Using Sword instead of puppet (...which is still best, apparently) if you want to stick to Python, though it's a very young project. Using such tools you can start versioning your configuration and environment, and store reasons for changes in commit messages.
  • Fabric for ssh the Python way :)
  • Virtualenv to isolate Python and manage dependencies
  • Buildout is like Maven for Python projects. It's used to maintain dependencies and deploy, though it can be overkill for many projects...
  • Augeas is not Python specific and supports many configuration formats

Ulrich then went through some of Martin Fowler's principles for refactoring among other things, and also talked about Jenkins, not Python but known as the "Wordpress of Continuous Integration" because it has so many plugins. Sonar can be used for code quality.


We tried something different for the second part of the evening and watched a video of a Pyramid talk. I don't think it quite worked, even at 30 minutes it felt too long. Perhaps we should try again with a video more likely to appeal to a wider range of people, or simply shorter talks. Fair play to Diarmuid for standing up and taking the heat of answering questions afterwards ;)

Leave a comment

wvdial: stackmaster assertion failure & EuroPython

At EuroPython, I happily took advantage of the prepaid SIM card that you could order together with your ticket. However tethering with Wind (Italy) was not to work that simply. On Debian Wheezy I ended up with the following error:

[...]
--> Modem initialized.
wvdial: utils/wvtask.cc:409: static void WvTaskMan::_stackmaster(): Assertion `magic_number == -0x123678' failed.

A bit of astute googling reveals that libwvstreams needs to be downgraded.

$ aptitude versions libwvstreams4.6-base # or apt-cache policy libwvstreams4.6-base
Package libwvstreams4.6-base:                        
p A 4.6.1-1                                       stable                    500 
i A 4.6.1-4                                       testing,unstable          500 
$ sudo aptitude install libwvstreams4.6-base=4.6.1-1

Tadam! wvdial now works. The same configuration as last year seems to do the trick (though on Fedora 16, the Network Manager's Mobile Broadband tool was easy to set up with Wind without  bothering with wvdial.)

[Dialer wind]
Modem Type = USB Modem
Modem = /dev/ttyACM0
Username = "wind"
Password = "wind"
Init6= AT+CGDCONT=1,"IP","internet.wind"
Leave a comment

EuroPython 2012 Let's go

I'm very happy to be going to EuroPython again this year :) Once more the talks I'm most looking forward to are mainly related to scalability, perhaps with a dash of internationalisation/encoding on the side. The tutorial on Django testing with Selenium should be interesting too.

Say hi if you see me! :)

Python Logo

Leave a comment | 2 so far

Python meetup, June 2012: Message brokers & Python ActiveMQ

Last Wednesday was June's monthly Python Ireland meet-up, this time with a talk by Fernando Ciciliati about message brokers and Python.

After a general  introduction on the advantages and concepts behind messaging, the main part of the talk was about ActiveMQ, a message broker under the Apache umbrella. Fernando explained that this was a broker mostly used by Java people and required a bit of work on their part to get it to play nicely with Python. They had to make significant changes and improvements to the existing libraries.

ActiveMQ is written in Java and designed for high-performance as opposed to reliability, and the default configuration reflects this. If you want your messages to persist after reboot and never be dropped, you will have to tweak the default setup.

The community is very active... which also means lots of bugs! Fernando recommends reading the tracker, as there will certainly be a couple of bugs that are relevant to your situation.

Thanks to the provided binaries, ActiveMQ is easy to install. You get a nice web interface to manage and monitor your queues and messages.

By default, STOMP is not installed and ActiveMQ is only configured to talk to Java via OpenWire. Enabling STOMP support is simply a matter of adding one line to an XML configuration file, and is the easiest way to communicate with Python.

There are several Python libraries available: stomp.py, stompy, Twisted also supports it... They selected stomp.py.

To test your ActiveMQ setup, you can simply telnet into the port and send messages, while using the web interface to see what's happening. The protocol is similar to SMTP.

The terminology used by ActiveMQ differs a bit from other message brokers, be careful when comparing them. (I wonder if this is due to using STOMP vs. using AMQP?). For instance, "topics" seem to be a way to broadcast in ActiveMQ, rather than a way to filter interesting messages.

As usual, the technical talks continued in the pub afterwards :)

Leave a comment

Adventures in Japan

In the middle of May, I went away for a couple of weeks in lovely Fukuoka, Japan with the goal of expanding my knowledge of Japanese.

Every weekday, I went to a language school, GenkiJACS. On the first day, my level was accurately evaluated through a written test and interview, and on the same afternoon I was put into a small class (5 people, myself included) with students at a similar level from all over the world. The lessons were held entirely in Japanese, with students' chitchat also happening in Japanese -- a lovely atmosphere :)

Support from the staff, both by email during the preceding months and during my stay, was top notch. The school also offers all sorts of native language materials for students to borrow, though considering the building was right above Mandarake, a manga/video games/DVD/etc shop, I must say I mostly bought my own... :)

I stayed with a host family for the whole time, which was wonderful in terms of language practice, making friends and experiencing varied aspects of Japanese daily life. The perceived lack of independence made me a bit twitchy at times though.

The concepts and vocabulary I learnt in and out of class have stuck well so far -- the class format is very good, with lots of reviewing after a new concept is introduced. In the end though, 2 weeks isn't enough time to acquire that much new knowledge and I mostly treat the experience as a very thorough level check. There are lots of conversations I had I didn't realise were within my grasp. Because Japanese people are often reluctant or unable to speak English (but always so nice and helpful!), I had plenty of opportunities to practice in varied contexts and I'm now a lot less shy about speaking in Japanese.

With only 2 weeks, unfortunately there was little time for tourism, though what I saw of Fukuoka City (Canal City, Kushida shrine and many other temples, Oohori Park, my local yakitori izakaya and kappazushi...) and the Fukuoka Prefecture (Dazaifu, Abura yama...) was delightful.

Definitely a wonderful experience. Study-wise, it was good for building confidence and boosting motivation. It was also good for cheaply acquiring plenty of contents in the language for practice... and making new friends! :)

Wooden staircase in the forest

Leave a comment

CESI 2012 "TEACHnology: Merging teaching and technology in schools"

Last Saturday I attended CESI 2012, a conference organised by the Computers in Education Society of Ireland. It's a conference aimed at teachers and this was the first time I attended. Even though as an IT professional I wasn't really the target audience, I really enjoyed the talks and left the day with my head full of ideas and really happy with the interesting conversations I had.

Random highlights and talk summaries from the day...

Opening talks

As part of the opening talks, Gerard McHugh told us that the lack of engaging content explains failing western schools. Even though many things in life have become more engaging over the decades, school hasn't: we need it to be more interactive, more collaborative and encourage participatory active learning.

For the keynote, Stephen Howell animately encouraged school teachers to do the PR for third-level courses :-) and help students find that spark to discover if they would enjoy a career in IT. The "3 Ds" should be taught in school: Design, Develop and Debug -- not all of them require computers or knowing how to code. Using software such as Scratch, students can be moved to a producer role as opposed to what they do with most wonderful modern devices such as the iPad or xBox, that are slanted toward consuming content. The goal is to get them to make their own games. The Scratch + Kinect demo was quite impressive :)

A brief history of the near future

John Hefferman looked at what technologies are currently being created, citing an interesting quote: "The future is already there, it's just not evenly distributed." If we look at what R&D departments are working on right now, there will be less of a surprise when it arrives into the classroom in 10 or 20 years. "The Horizon Report" relates technological innovations that are coming up. John ended the talk by telling us examples of how all this will affect history teaching and the classroom in general.

One of the questions was about how to bring some of the tools to the classroom, when there are school and curriculum constraints. The answer was that it's better to ask for forgiveness that permission, and start under the radar initially.

Game-based learning in Irish education

Patrick Felicia is doing research on the impact of games in education. His surveys indicate that most teachers agree games are a good learning tool, that improves plenty of skills (with a bit of hesitation regarding social skills, which is likely due to people having different types of game in mind). However despite agreeing on the benefits, only a tiny percentage have actually used any in their classroom. Most of the talk took the form of a conversation with the audience, aiming to figure out why this is and people's thoughts about it.

The main problems and constraints strongly relate to the curriculum and time constraints. There is not a lot of content tailored for the Irish market. Teachers suggested a portal of suitable games, and bringing workshops on how to use them to the schools to make sure people attend and learn about it.

Someone suggested, inspired by Stephen Howell's keynote, to have children develop the content :-) This way they get to use their creativity, meaningful content is created and they are taking responsibility for it. Teach to create!

The iGBL is an Irish conference on game-based learning.

The LiveScribe pen in action

Adrienne Webb explained to us what the LiveScribe pen is, how it can be used and how she uses it to provide additional resources to her students. The pen is a very interesting piece of technology that records what you're writing and your voice, which you can then upload or send as a video. There are cool additional little features, such as clicking an element of the video to listen to the playback of what was said when that particular element was drawn.

She used it to provide sample exam answers, so the students can focus on what they want and ask questions only on what they are having difficulty with. This worked better and more efficiently that trying to cover every question for everyone over 40 minutes. The students - in an exam year - really took to it.

Social networking with our students

Catherine Cronin related her very interesting experience on using social media such as Twitter and Google Plus to interact with students for a third-level module, touching on themes such as digital identity, privacy and authenticity.

Currently there is a tension between the current model of delivering education, standardised, static and stale versus a student-centred model. Meaningful learning occurs with knowledge construction, not knowledge reproduction.

There are 5 stages to go through:

  • Awareness (of what is going on)
  • Commitment (which requires time and learning)
  • Access (to the appropriate technology)
  • Authority (to change things, which is easier at the 3rd level since you can do what you want for the modules you teach)
  • Design

This is about challenging students while still honouring who they are and how they work.

The Google Plus experiment was leaky (in that G+ makes it easy to re-share stuff that was submitted privately to a circle), though this accidentally made the conversation more authentic by allowing the author of a book they were studying, Jeff Jarvis, to join in.

There is of course a dilemma between being graded and having an authentic discussion. From the student's point of view, there was a wide spectrum of opinions with regard to the usefulness of social networks, thoughts on privacy and comfort expressing opinions in public.

Student comments covered a wide range in terms of appreciation of the experiment. The general opinion seems to be that it was useful, but/and messy!

The talk Q&A reflected on the dangers of having students participate in that kind of public discussions, at a stage where they're likely still trying on different identities to find themselves. This is going to happen anyway, so it might as well be within the context of a class with someone to offer guidance.

Moodle in the classroom

Declan Donnelly gave a nice introduction to Moodle by explaining to us how his primary school uses it -- all of which is also applicable to the secondary level.

The presentation mainly focused on the possibilities offered by interactive exercises, notably by linking with SCORM compatible software like Hot Potatoes, which is better than the basic Moodle quizzes.

Thanks to Moodle it's easier to share resources and do grading and assessment. It acts as a digital link between home and school, both to do the work (including drafts) and show off accomplishments to the family.

This link also applies to staff, as the school they use Moodle to publish policies and meeting notes, in a section only accessible by the staff.

Enhanced Learning Futures

After a full day of listening to tremendously interesting talks coming straight from the classroom trenches, I felt the "capstone address" resonated a bit hollow -- it was an excellent presentation but it nearly felt too polished!

Still Steve Wheeler brought up plenty of good ideas and food for thought, regarding the direction society, technology and education are going toward. Tools shape our behaviour, the more we use them.

Some examples of societal shifts: Amazon now sells more Kindle books than paper books. 1.5 billion mobile phones have been sold. Girls are catching up in terms of gaming trends. The gamification of learning can lead to deeper learning because we want to repeat the experience.

Learners need to acquire "digital wisdom". Lovely new term: darwikinism! The survival of the fittest content.


Looking forward to next year's event :-)

Leave a comment

<~ Older posts Newer posts ~>


Archives