In the beginning...

The FOSS Outreach program has officially started!

I have to laugh a little about myself. A few days ago I was hoping that I could jump in and start doing something wonderful. As I started asking questions about the system, one of the first things I noticed was that I didn’t understand the product. Sure, the basic idea is GNOME Keysign is a tool to sign keys without the use of a key server. Back in October when I began learning about what this meant I had a simplistic view on OpenPGP. If you want to send a “secret” message you need to have a way to encrypt the cleartext to ciphertext and then back to cleartext. If you’re like me, you might start to imagine someone with a strong background in mathematics and cryptography drinking copious amounts of redbull and staying up all night fighting the war on cyber crime.  Yes, take that <insert current global enemy here>. Unfortunately this might make you want to slowly back away, but sending encrypted emails is much easier than you might imagine. The encryption algorithms run quietly behind the scenes while you’re blissfully unaware of the poor souls who probably spent their 20s working on cryptography. The “key” (hee haw!) to encryption is having the key necessary to lock and unlock the encryption. Simple enough, but how do you securely send this key to your friends? If they live near you could pedal your bike over and tell them what it is. However, this doesn’t work for people who live outside of your town or someone that you’ve never met. To solve this solution, you have an asymmetric keypair. One key is your private key that you never give out to anyone while the second is a public key that you can shout out to the world on the rough top while someone is filming for the next viral youtube hit. Okay, you probably don’t want to do that since part of protecting your data is conservatism, but the point is, you shouldn’t be able ascertain the private key from the public key. The neat thing about the keypair is that if one is used to encrypt a document and the other can decrypt that same document, you know that those two keys are part of the same keypair. This is great because it solves another problem; how do I know the encrypted document is sent by the correct person? Well, because the public key can only decrypt it if it’s part of the keypair for the private key. However, what if I’ve never met this person? Now we can start talking about keysigning and it’s advantages. My public key is part of a digital certificate that also includes certificate information, such as my user id, and one or more digital signatures. Others sign my key with a digital signature, which authenticates my public key. So if I know Adam and trust him, and Adam knows Betty and trusts her, ergo I can trust Betty. The more signatures I have on my public key, the more it can be “trusted.” All of this seams fairly reasonable and logical. After downloading the GnuPG package, I easily made myself a couple of keypairs and was off to protecting my personal data. Eazy Piezy.

One of the things that I failed to grasp was why. I pity the poor NSA analyst who has the misfortune to read any of my emails. They must be incredibly boring and riddled with aggravating grammatical mistakes. However, as mundane as they are, they are part of my data that I want to keep protected. I wouldn’t let officers inspect my house whenever they wanted. Whether you avidly follow the news or not, Snowden has become a household name, usually associated with the discovery that the government is encroaching on our civil liberties more and more. OpenPGP is a set of encryption protocols that gives the individual the ability to encrypt their documents with the aforementioned keypairs. I’m a bit of a lazy person and I can rationalize myself out of encrypting my meaningless one-line email, but I do want to insure that I have the choice to encrypt my data if I want. Here is the call to arms. If no one encrypts their emails or cares about encrypting their emails, it makes it that much easier for the government to take away this option. Here’s an analogy, most people I know have a password on their phone. Could you imagine the uproar if congress tried to initiate a bill that revoked this feature on phones? It wouldn’t happen. A good resource is written by Phil Zimmerman here, http://www.philzimmermann.com/EN/bibliography/bibliography.html.

The problem with the previous block of information is that it provides the background for GNOME Keysign, but it doesn’t tell us specifically why it does what it does and more of the technical details of the program. Again, Keysign is a tool to sign keys without the use of a keyserver. Why would you want to do that? Well, part of that answer is that the unique key fingerprint sequence of numbers and letters are overlapping between users, which can lead to downloading the wrong public key from the key server. Keysign circumvents this problem my downloading key information from a local network. When I start up Keysign I immediately see a user-friendly GUI with two tabs, Keys and GetKeys, which represents the client and server sides of the program. If I proceed with Keys as in I want someone to sign my key, Keysign fetches my fingerprint and encodes it in a QRcode image. You can choose to transfer your key fingerprint by transferring the actual sequence or by scanning the QRcode. Underneath the GUI the program is publishing my key information to the local network. If instead, I choose to GetKeys as in I want to sign someone’s key, I can either enter in the fingerprint manually or scan the QRcode. The program then grabs the key information from the local network and then adds it to my temporary keyring. It then signs it with my digital signature and sends this information back to the email associated with that public key to insure that the signature is going to the intended email of the person whose key I just signed.  Viola, signed keys!

Sadly, it took quite a bit for me to figure all of this out, which is why I felt like I needed to make light of myself for thinking that I would just, you know, start solving issues from the get-go. Lucky for me, the other participants of the program have expressed that they are all in a similar situation, which relieved some of my concerns about my own performance. Strength in numbers, right? Hopefully, my next post will involve a more profound inspection of the inner workings of the project. J

Transition

I should be focusing on something else at the moment (ahem), but I know how anti-climatic finishing a PhD is for many students. So, again I'm going to write about the moment so that maybe it will feel a bit more "official." On Tuesday I handed over my thesis to my committee and to the thesis office for preliminary review. I had to print out the one that I turned into the thesis office. There was something very satisfying about holding a physical representation of my dissertation in my hands. It was big, and I felt the size was a good representation of all the work that I've put into it the last couple of months. Also, I've never considered writing to be my strong suit, although for most people that's probably true, so it's kind of fun to realize that I CAN write a book if I wish. 

Along with finishing the dissertation, I've ordered the food, reserved the auditorium, printed off the official pages for my committee to sign, and set a date for my last day in the lab where I will hand off all my reagents and lab notebooks. After working on my thesis for so long, I can hardly believe that I will be done in a week. Time slowed down to a crawl while writing the thesis, only to speed up to it's maximum velocity in these last days as I finish up my graduate student duties. 

I wish I had something more profound to say to mark the occasion. It's more of a relief than anything. All I can say is: I can't express how much I'm looking forward to FINALLY making the complete transition to building my programming skills full time. 

Hurray!!!

Okay, I feel a little bad because I haven't talked about the project that I contributed to or applied for round 9 of the Outreach Program. I will have to do that in a later post. Really though, I should give myself a break. I AM writing a dissertation for crying out loud.

Often times, I let good news slide by unnoticed as I pursue the next goal. So I want to savor the moment for just a little bit and I will do so by highlighting it in my blog. Also, I want to express my gratitude. Myself and the project was selected for the Outreach Program!!! I will be working with GNOME on their keysign application. I am so happy and thankful to have been chosen for this opportunity. I think it will be very satisfying on multiple levels, especially the part where my work will potentially affect a much larger group of people. Additionally, I am excited that I get to share this experience will all the other Outreach Program participants who are coming from such diverse backgrounds. I could go on but I'll summarize the moment with two words, thankful and excited.

There's so many projects, which one should I choose to pursue?

I want to switch gears and talk about my own experience in starting to contribute to an open source project. First I want to make a big disclaimer. Applying to OPW and choosing from active projects with vetted mentors made things A LOT easier. An advantages of this is that you have someone to contact who is first and foremost interested in mentoring someone, and willing to do so for a substantial amount of time.

OPW has several participating organizations to choose from, and under each of those organizations there are several projects with available mentors. The choice of projects is slightly overwhelming, since they all sound interesting. Since I am not an experienced developer, I thought it would be better to choose an organization whose product I was currently a user, thus providing me with some familiarity. My next selection criteria was language proficiency in the project's source code. Goodbye javascript projects! This narrowed the projects down to a reasonable amount to explore and subsequently make an educated choice. I found several suitable projects and honestly I would be more than happy to work on any of them but GNOME Keysign sparked my interest the most. It's a small project with less infrastructure than some of the other projects, which I initially had some concerns about but now I see as a potential strength. My previous post has a link to the advantages and disadvantages of choosing a small versus larger project. For me, I think there will be a lot of valuable insights into learning how a newer project is developed. I contacted the mentor of the project, Tobias, and found him to be prompt in responding and a very agreeable fellow. :-) After discussing a feasible project timeline, the advantage of working on a smaller project really shined. There was a lot of variety, which I think will maximize the amount of things that I could learn. So far, things have worked out really well. The application process requires at least one contribution and I have been able to submit a few and hope to submit more, which brings me to the realization, "Look at me! I'm contributing!" Regardless of being accepted into the program, I've already achieved my goal of getting involved in open source.

I hope, however, that for someone who is reading this who is either not eligible to apply or not obsessed with OPW like I am, finds that my experience is generally translatable. Had I not found OPW, I would most likely either be at the Mozilla or GNOME bugzilla page facing similar dilemmas and wondering where to go next. It probably would have been more of a hit and miss, but I think I would of followed a similar path as above.

Getting involved with FOSS

I mentioned in my last post that the GNOME OPW page was a great place to find information on how to get started in contributing to open source, regardless of your gender. It wasn't that long ago that I was at a total loss of how to get started, and now I'm almost overwhelmed by the list of resources at my disposal.  When I asked others about contributing, the advice I received was to look through the list of projects on github, particularly the trending repositories. Github is a very useful tool in finding open projects; however as a beginner it was like finding a needle in a stack of needles, without knowing what the needle looked like.

Before I forget, I wanted to highlight a few pages that I found very helpful. The first one is kind of a no-brainer https://openhatch.org. It matches your interests with prospective projects in a much friendlier format than other sites. Simply put, their mission is "lowering the barriers to entry into the open source community and increasing diversity." I have to say, I felt a shade of crimson rising up into my face when I admitted that I had never heard of this site. You would think that this might be the first place you'd find when searching "how to contribute to open source." In my defense, that exact google search did not display the OpenHatch result on the first page.

With so many projects available to work on, how do you find a good match? My own personal advice would be to find a project with a very clear developer's page and list of resources on how to contribute. A good, basic "how to contribute" page has information on how to build the system, where to find tasks or bugs to work on, and how to submit these patches. I'll use GNOME Love as a great page for newbies seeking to contribute, https://wiki.gnome.org/GnomeLove. GNOME love has the previous attributes but it also has tutorial pages, a list of mentors to contact, and most importantly a mailing list and irc channel devoted specifically to those needing additional help. More than that, they even have a mock bug that you can report, fix, and patch with step by step instructions on how to it. Here's another page that I liked, http://blog.melchua.com/2010/10/08/possesa-fri-5-minutes-of-improvisation/. An experienced developer takes us through a five minute tour of what she looks for in an evaluating a prospective project that she is interested in getting involved. I like this page because it's pretty helpful if you're looking at several projects and you don't want to spend all day deciding if one of those projects is for you.

The last resource is from a previous wikimedia mentor to a former OPW student. She's clearly thought deeply about mentoring and she has a lot of useful advice. She is also a prolific writer and you may find her blog of general interest, http://www.harihareswara.net/sumana. She has several entries that include help for new open source people, what a good mentor/internship relationship should look like, choosing a young versus older open source project, etc... You could spend several days exploring her blog.

OPW

I woke up the other morning to find an email from a fellow Girl Develop It! member who had sent out a group message about the Outreach Program for Women (OPW). She didn't say much about what it was, but I was pleasantly surprised when I followed the link, https://wiki.gnome.org/OutreachProgramForWomen. What I found was a program to promote women  working on FOSS projects by providing them resources to find a mentor and the monetary means to work on a project for ~12 weeks.  Historically, women have always been extremely underrepresented in Computer Science; however the percentage of women working in FOSS is even lower than that of industry, http://geekfeminism.wikia.com/wiki/FLOSS. For instance, women developers in Debian is abysmally low at 1.8%, while women represented the Ubuntu community at 2.4%. There are a few communities who are doing better, such as women make up 10.3% of GNOME foundation members. It's not hard to put two and two together to realize the potential benefit of more women participating in FOSS. OPW is working to improve these numbers and there's evidence that the program is successful. You only need to take a look at some of the contributions of past participates to realize that these women are having a very positive impact.

As soon as I read the brief synopsis of the program, I knew that this program was very much aligned to my current goals. Thus far, just the collection of information about FOSS, mentors, projects, blogs of past participants experiences, etc... has been an invaluable tool in helping me to get involved in FOSS. Unfortunately, Mozilla isn't participating this round, but I found a GNOME project that I'm getting more and more excited about. Despite being in the middle of finishing my dissertation, I've managed to make the required small contribution in the form of a README page. The closing date for the program application is fast approaching, and time is tight to make a coding contribution as well. Regardless of being accepted into the program, OPW/GNOME has already helped me towards my goal of contributing to FOSS by putting me in contact with a mentor for a project that I'm really excited about.

Learning programming the hard way

Before delving into where I'm at, I wanted to provide more of a back story. However, I think that I will have to jump around and things are not going to be in chronological order. My goal with this blog is show people how I got from A to Z. Let's hope I get to Z, right! : )

From what I've gathered, it seems that one of the most important things that you need in order to get someone to pay you to program (yes, eventually you'll need someone to pay you to do it), is to have some kind of demonstration of your abilities. I'm talking side projects. It makes sense though, you learn, you practice, and you have a side project to show for it. So, I've started a list of things I would like to learn and a side project that can go with learning that skill. However, one of the things that I think would make me a better programmer is looking at other people's code. For myself, one of the best ways to accomplish this was to work on a FOSS project. When I first started looking around I didn't know where to start and how I would start working on something. A couple of weeks later, I don't know how I will be able to focus on one project when there are so many things you can do. When I first started looking I got a little lucky, I absolutely adore quora.com. I noticed that someone asked the exact question that had been on my mind, "Which open source projects are simple enough for beginners to start working on?" Yes! Exactly! So this led me to bugzilla.com or more specifically joshmatthews.net/bugsahoy/, where there you can sort the available Mozilla bug fixes by project type, language, and if they are a "good first bug." In addition, the developer pages, which includes pages for new contributors, are clear and easy to understand for the beginner. It's hard enough to be thrown in a new project, but even harder when people expect you to know information that is cryptically conveyed. 

After building firefox into an isolated Linux virtual machine, I realize the gap between taking CS classes and working on a project in the real world. First, I take a look at the code. You would expect that these projects would contain massive amounts of code separated into many files. Even knowing this, when I first opened it up and started looking around all I could say is wow! Wow! I'm still speechless at the number of files and lines of code.