Women in Open Source

The discussion started with one simple stat: only 4% of Summer of Code participants are women. Comments suggest that the numbers for open source software in general are even worse and that, although not ideal, the field of computer science in general does seem to be doing somewhat better. The question posed was simply this: why are women interested in development shying away from open source in particular?

My first thought on this was that women tend to appreciate social contact. And I'm going to guess that this means face to face, bona fide real-life interaction, not just the virtual variety. There seem to be relatively few opportunities to meet other members of an open source project's community other than the occasional conference. Would most women enjoy working with people they've never met, knowing only their online personalities?

A timely technology news update from ACM included an article about why there aren't more women working in high-tech in general. Sadly, I can't find the article now, but the main point was that many women are turned off by the working environments found in most high tech places. With open source development largely happening online only, it goes without saying that there isn't much of an 'environment' at all. No lunches with coworkers, no fun days, and no jokes during team meetings. It is also possible that the virtual environment created by the community would be suitable, but that women aren't able connect to their fellow developers in a meaningful enough fashion to discover this. This comes back to the whole social contact thing.

Finally, ask yourself which gender is more likely to come home after a long day of work (possibly of coding) and fire up the laptop to scratch that burning itch by working on some project that doesn't result in any kind of financial gain. You're picturing a guy, aren't you? Even women without families seem to enjoy taking on activities that have nothing to do with work during the evenings and weekends. It's not that they didn't enjoy the programming they did during the day; it's just that there are so many other things to get done after the steam whistle has sounded.

I know I can relate to each of these three issues myself. I definitely appreciate the social aspects of a regular job. I always look forward to fun days out of the office, and getting together with coworkers over lunch. Heck, I even enjoy meetings because of the opportunity to interact with others! I have found that even regular high-tech companies can often fail to satisfy my social needs - too many employees don't tend to want to do anything except work on their piece of the project. And yes, these tend to be the males!

Having said that, however, I can also say that I can enjoy working on my own as well. So far, I don't mind the 'reclusiveness' of open source too much; I guess we'll have to see what my feelings are at the end of an entire summer of doing it. I can absolutely see myself contributing beyond the Summer of Code, but I could never put in the huge amounts of time into open source (or any coding project) that I see some guys doing. After all, I have to save time for laundry, gardening, motorcycling, taekwondo, yoga, snowboarding, ...

Summer Reading List

I reckon it will be a busy summer this year. In addition to planning my wedding in August and participating in the Google Summer of Code, I have quite the extensive reading list. Of course, this is self inflicted, so I have nobody to blame but myself, but nonetheless, time is running out!

Feel free to tell me more about these books if you've read them, or others that cover similar topics.

Here are some of the books I will be tackling:

Scientific Dumbology: Gaffes, Foul-ups & Blunders
Robert Youngson

Scientific Dumbology is an investigative and humerous account of the errors into which seemingly infallible humans have fallen, giving a valuable perspective on the risks and benefits of scientific advance.

I picked up this book from the bargain bin at the local Indigo bookstore. I figured that since I thoroughly enjoyed A Short History of Nearly Everything, by Bill Bryson, I must like reading about the history of science.

I've read through a few chapters of this book already. It's no masterpiece, but I am still not sick of reading about the mess-ups necessary to scientific advancement. It is also a good reminder to look very critically at the "science" surrounding the hot topics of today's media, like global warming.

Visual Computing: Geometry, Graphics, and Vision
Frank Neilson

Visual Computing: Geometry, Graphics, and Vision is a concise introduction to common notions, methodologies, data structures, and algorithmic techniques arising in the mature fields of computer graphics, vision, and computational geometry. The central goal of the book is to provide a global and unified view of the rich interdisciplinary visual computing field.

A professor lent me this book last September, but I was too busy with school and extra curricular activities to sit down and read it. The topics covered pretty much describe the area I want to work in for my upcoming masters, so this is a must read for me.

After reading the first few chapters, I can say that the book isn't the best student text I've seen; there are several errors and the author makes too many assumptions. Still, it's a great survey into all the topics I want to work in but know little about.

Gödel, Escher, Bach: An Eternal Golden Braid
Douglas R. Hofstadter

Twenty years after it topped the bestseller charts, Douglas R. Hofstadter's Gödel, Escher, Bach: An Eternal Golden Braid is still something of a marvel. Besides being a profound and entertaining meditation on human thought and creativity, this book looks at the surprising points of contact between the music of Bach, the artwork of Escher, and the mathematics of Gödel. It also looks at the prospects for computers and artificial intelligence (AI) for mimicking human thought. For the general reader and the computer techie alike, this book still sets a standard for thinking about the future of computers and their relation to the way we think.

This one hardly needs any introduction. I actually first learned of it way back in my OAC (equivalent to grade 13) algebra and geometry class when my teacher somehow associated it to what we were learning. Intrigued, I bought it right away and got through a few chapters. I doubt I could have possibly fully understood it at the time, though the notions of strange loops probably helped when I first learned recursion later on. I soon ran out of time to finish reading the book.

It was a fellow Summer of Code participant that encouraged me to start reading this one again, though not directly. Brian Jorgensen has been guiding us through the book on his blog, Straight Up Coding. I'm already behind I suppose, but that's alright - I'm just glad that I'm rereading the book at all.

The Google Summer of Code Surprise Book
Author yet unknown, though he or she supposedly signed the book!

I should receive my surprise gift in the mail soon. According to those that already got theirs, the contents are somehow applicable to our three month code-a-thon that, incidentally, officially starts today.

Scanning My Eyes

Last week I made the trek to downtown Ottawa for the very special purpose of scanning my eyes. A few dollars for parking, forty for the scan, and a few minutes of my time was all it took to get a detailed (and colorful) map of my corneas:

The reason for getting the scan is that I have keratoconus, a "degenerative non-inflammatory disorder of the eye in which structural changes within the cornea cause it to thin and change to a more conical shape than its normal gradual curve." With exact information on the current shape of my cornea, I may be able to get hard contacts that fit better and are therefore more comfortable.

So what does this have to do with computer science, you ask? I'm glad you did! I'm interested in studying visual computing for my upcoming masters degree in computer science. By this I mean computer vision, computational geometry, and graphics. As it turns out, medical imaging is a major application of computer vision:

As a technological discipline, computer vision seeks to apply the theories and models of computer vision to the construction of computer vision systems. Examples of applications of computer vision systems include systems for ... modeling objects or environments (e.g. industrial inspection, medical image analysis or topographical modeling).

Take the example of creating a better fitting contact lens. Now, I cannot claim that I know exactly how they do this, but let's imagine it: the sensors collect thousands of points of data that should indicate the 3D shape of my cornea. These points can be reconstructed and then used to machine a matching lens. Now my lenses will sit on the proper part of my eye and not move around, irritating it. Sounds like a good deal to me!

There is a pretty good description of the machine that took the scan on this Strong Health website if you want to know more.

LGM: GIMP Redesign Project

A passion-in-waiting tucked in the back of my brain is usability. I haven't had much opportunity to give it the time and study it deserves; I haven't even read the staple book The Design of Everyday Things by Donald Norman (but it has been on my Amazon wishlist for a while now!). I have taken an interesting course that taught, among other things, user and task analysis and some basic usability concepts. I believe this subject is terribly important for any developer to at least be aware of, yet is given much less attention than it deserves.

And so it was with great interest that I attended the LGM talk by Peter Sikking and Kamila Giedrojć entitled "OpenUsability - Project overview and first results from the OpenUsability GIMP redesign project."

The GIMP redesign project is a pilot project for an OpenUsability initiative that would have student projects selected and supported in a fashion not unlike Google's Summer of Code. Ms. Giedrojć was the student chosen for this trial run.

Mr. Sikking began the presentation with GIMP's product vision. According to an article by Jim Highsmith found here, "creating a product vision statement helps teams remain focused on the critical aspects of the product, even when details are changing rapidly." Clearly, knowing what GIMP is and is not, the redesign can focus on the features that truly matter.

So, according to the presentation and the project's wiki page, GIMP is:

• Free software
• Intended for photo manipulation
• A high-end application for icons, web pages, and art for user interface elements
• A platform for image processing algorithms
• User configurable such that tasks can be automated with little or no development skill required
• Easily user extendable with one-click installation of plug-ins

Alternatively, GIMP is not:

• Photoshop
• A painting program (such as Corel Painter)
• A web-page mock up program
  
• The only Linux based pixel-oriented application on the face of the planet

Armed with this foundation, thoughts turned to usability. One could argue that the goal of this project would be to make GIMP intuitive. This is completely false, as no software is truly intuitive; instead, the Three E's must be considered: ease of learning, ease of remembering, and ease of use.

Designers must choose where their software will lie in this triangle, remembering that trying to balance all three could be a dangerous idea.

Mr. Sikking tells us that GIMP aims to have the highest ease of use, and needs not worry as much about ease of remembering. Ease of learning should be of slightly higher concern than ease of remembering. My feeling on the reasoning behind this is that the software tends to be used often enough that the typical user won't have large gaps between sessions in which to forget everything.

GIMP lies in the bottom right of our Three E's triangle. This can be compared to learning the violin: it is not an easy instrument to learn, but once it has been mastered, beautiful things can be created; however, the musician must keep practicing.

The next part of the presentation detailed the steps taken so far in GIMP's redesign. First, a summary of the software's current functionality was narrowed down to just eleven pages; this took two and a half months to complete. Then, with users observed in their workplace, eight user scenarios were developed, which can be found here. Finally, twenty-five expert evaluation sessions were conducted based on the user scenarios. Notes on this session can be found here. The analysis of the expert evaluation is currently in progress.

The final topic in the talk was a list of the top ten user requests and a brief analysis of each. This portion was mainly delivered by Ms. Giedrojć, and then (unnecessarily) summarized by Mr. Sikking. The key theme here was to use the product vision and user scenarios / expert evaluations to determine which features should be changed or added.

For example, request number nine was for the ability to paint with natural brushes. However, noting that the product vision states that GIMP is not a painting program, there is actually no real requirement for this. Users can write their own plug-ins as desired, but there is no need to consume developer effort on such a request.

As another example, improvements to the text tool was request number eight. Users into original art and web graphics were particularly adamant about this one. Analysis showed that there was no requirement for page layout in particular, and that there should not be one layer per every piece of text. Furthermore, better styling and typographical control is required.

This last example provides the perfect lead-in to my Summer of Code project which will be all about text tool improvements as well. In fact, my first task will be to redesign some of the text UI in Inkscape. The kind of analysis done for GIMP can definitely be applied, though with a smaller scale, to my own work. I'm particularly excited about this because I may finally have the chance to unleash this passion for usability.

It should be obvious by now that I quite enjoyed this talk. It was well organized and reinforced the ideas that I learned in school. I hope to keep an eye on the progress and check out the results, especially because the not-so-usable current version of GIMP never really earned my attention. We'll see if the redesign does any better.

LGM: Introduction to SVG

The second talk Andrew and I attended at the Libre Graphics Meeting was entitled "Introduction to SVG" and given by Inkscaper Ted Gould. His aim was to give a general (and not overly technical) overview of what SVG is and what it can do.

Mr. Gould touched on some of the basic elements of SVG (Scalable Vector Graphics) such as gradients, markers, clones, text on a path, inserted bitmaps, alpha transparency, patterns, and so on. Not being particularly familiar with SVG prior to joining Inkscape, and now just learning its capabilities, I was pretty impressed to see via the examples provided all the cool things that SVG has built right into its specification.

This photo realistic car [found here] was made in Inkscape, and really goes to show what amazing things can be done with SVG.

Mr. Gould noted that SVG is XML based, and uses CSS for styles. He gave an example of what a small file that defines a simple square might look like. He also explained the three different profiles used for SVG: tiny (which implements only a small subset of functionality, and is therefore suitable for cell phones), basic (which has a larger subset than tiny, but is still suitable for devices like PDAs), and full (the name speaks for itself). Inkscape is currently aiming for tiny, but once that has been reached, the journey to basic and then full will have begun.

A couple of big bonuses of SVG were mentioned by Mr. Gould. For instance, thanks to the use of XML, SVG files are human readable. This is very good news for Google and accessibility: the search engine can easily parse the contents, and screen readers can "speak" the file. Also, internationalization becomes less of a pain. Graphics with text can be translated just as easily as HTML text, so artwork like logos can be translated easily.

I enjoyed this presentation quite a bit more than the previous talk on the Open Document Format. Maybe it's because Mr. Gould didn't seem to have any kind of hidden agenda, but was still obviously knowledgeable and passionate about the topic at hand. Of course, my personal interest in graphics in general might have something to do with it, too. Either way, I believe that this presentation served all audiences -- the artists, Inkscape developers, and other developers -- rather well.

If you want to learn more about the SVG format, check out the main W3C page for SVG. Don't forget to download Inkscape for all your SVG editing and creation needs!

LGM: Why Open Standards Matter

The first English talk of the Libre Graphics Meeting was given by Louis Suárez-Potts, Senior Community Manager of OpenOffice.org, and as far as I can see, quite the idealist. The talk was called "Why Open Standards Matter: The Open Document Format" and discussed digital documents in general, the Open Document Format in particular, and freedom as a responsibility.

Mr. Suárez-Potts tells his audience that he is a bit of a historian and treats us to his version of, essentially, the development of documents. Long ago, all formats were available to anyone who had the right education. Special tools were not needed. Unfortunately, it was the politically powerful that controlled the ability to learn the skills required to produce and consume the documents; that is, the powerful more or less owned the information. Fortunately, the formats themselves could be considered transcendental.

Fast forward to today. With modernity comes accessible education, which results in the "exchange and discovery of ideas with the past, present, and future." While politics no longer endangers our information, Mr. Suárez-Potts argues that technology does.

The big bad guys of the day are the Microsofts of the world and their proprietary document formats. "Democracy [and] modernity [are] challenged by a neo-feudalism, and collective memory [is] lost." That is to say that the proprietary digital formats of the day are in the control of the elites who own them.

Indeed, according to Mr. Suárez-Potts, the "triumph of modernity ... comes to nothing if the formats capturing personal and collective memory are proprietary." So when a company (like Microsoft, just for argument's sake) goes out of business, it takes all that knowledge about its closed format with it, locking away the information stored within.

The moral of the story is that while proprietary technology seeks to limit the ability for others to intervene, free information promotes commercial and cultural growth, and open standards impose no limits.

---

Let's pause for a moment to reflect on what Mr. Suárez-Potts has said so far. He argues that the formats used throughout history have transcended time; it was simply a matter of the average simpleton not having the money, status, or power to learn how to access it. Now that that blocker has essentially been removed, we have been able to go back and recover the information left behind.

I'm not convinced that knowledge stored in proprietary formats will be any different, even if the reasons behind the "closed-ness" are different.

After thousands of years since Egyptian hieroglyphs were regularly used, we have been able to decipher the meaning behind discovered texts. Granted, it took a long time -- explanations and translations had been attempted as early as the fifth century, but success came as late as the nineteenth century -- but determination and careful study prevailed.

Egyptian hieroglyphs once had an "open" standard in the sense that the meaning of various glyphs was well known as the knowledge of how to read and write them was passed down through the generations. It wasn't until the fourth century that few Egyptians could read hieroglyphs and the format became, in a way, closed.

If the knowledge stored in the hieroglyphs was not lost, why should we consider the data in an MS Word file as such? Furthermore, if an "open" standard like hieroglyphs could be lost over time, then who's to say the same thing can't happen to the Open Document Format and other such standards? Finally, what about the possibility that the way documents are digitally stored will give way for something we can't even fathom, not unlike the way that carving in stone gave way to paper and paper gave way to computers?

---

Back to the presentation.

The Open Document Format, or ODF, is purported to have no secrets, and be completely transparent and accountable. It is about encouraging the reuse of standards. However, it is important to avoid confusion about ODF -- it is not an application, it is just a standard. It needs to be implemented in software like OpenOffice to be useful.

Apparently governments and other areas of the public sector are finally warming up to the idea of open standards. Although many of these formats are implemented in free software, many potential users have seen open source as a source of pain rather than value, and figured the community creating it must be full of communists or some such thing. However, those that do use it may be buying into the notion that "only by focusing on open source can nothing happen." This "nothing" boils down to the loss of important data.

Though not the final point in the presentation, the last part that meant much to me was Mr. Suárez-Potts' assertion that buying proprietary software is like buying into an addiction. He also pointed out that Microsoft's OOXML format has a specification ten times the size of the Open Document Format, so even though it is technically open, it is too hard to implement and could pretty much be considered closed in the end.

---

I may be missing his point here, but Mr. Suárez-Potts' assertion that buying proprietary software is somehow a terrible evil was pretty insulting. Especially coming from a guy that happily booted up his beloved MacBook with which to give his presentation. Oh, wait -- Mac is "cool," so I guess it's ok to like "cool" proprietary products.

Louis Suárez-Potts is obviously a smart man. He even has a PhD in English. But his message was partially lost on me because of his extreme attitudes. I am convinced there is a place for open standards in the digital world, but I don't buy the notion that information is all but locked away when it is stored in proprietary formats.

Libre Graphics Meeting

Soon after joining the Inkscape developer's mailing list, I was introduced to a conference called the Libre Graphics Meeting. In its second year, the event was held in Montreal on May 4th through 6th at École Polytechnique de Montréal. Being from Ottawa, a mere two hour drive away, I felt it was practically mandatory that I make the trip to meet fellow Inkscape developers and learn a bit about the open source world.

Andrew (my fiancė) and I woke up at 5:45 a.m. on Friday morning. Understand that, for software developers, this feels like the middle of the night, so I was proud of Andrew for actually falling out of bed on time. After some breakfast for me and coffee for him, we hit the road. The drive was mostly easy, though the traffic in Montreal at 8:45 a.m. was slightly heavy, making our drive a bit longer than the estimated two hours.

We quickly checked in to Les Studios Hôtel and ran up the hill to the conference building. We made it just in time for the first English talk (many were in French), and one of the most interesting to Andrew: "Why open standards matter: The Open Document Format." I will post about this and other interesting talks later.

For most of the day Friday we listened to more talks, and then we went back to the hotel to bring our stuff up to our room. I should really put quotes around the word hotel because it was really more like a jail that we paid to stay in. The room was tiny (even smaller than expected), and the walls were concrete blocks that were painted white. The bed was probably worse than sleeping on the floor. The things we were supposed to put our heads on were the worst excuses for pillows we've ever seen. Seemed more like folded up tarps with pillow cases.

As you can see, our room was rather depressing.

But enough belly-aching about that. We survived, and it was only $50/night.

Besides, the view from the 15th floor wasn't so bad!

Thanks to the "Grand Souper" being held that night, time in the jail cell was cut short. Some buffet food and a free glass of wine fueled us as we chatted with Inkscape developers and some new friends from other organizations. It was during this time that Andrew and I gained the most insight into the open source world.

The remaining two days of the conference had fewer talks we were interested in, so we took the opportunity to walk around downtown Montreal, ensuring a stop at two of the many local brew pubs.

Andrew enjoys a liter of micro brew from the first brewpub we stopped at.

My reflections on the open source side of things should come through in later entries about the conference's talks, but I can sum the experience up with one thought: Supporters of open source are nothing if they are not passionate.

Google, Summer of Code, and Open Source Software

My name is Gail, and I'm an open source newbie.

Surprising for somebody who just graduated computer science? Perhaps, but certainly not irreversible.

I'd heard of a few popular open source packages, including OpenOffice.org, and even used Eclipse for many school projects, but I didn't know much more about the world of open source than what the die-hard fans in my class ranted about. Some of the key questions in my mind included how people in open source made money and how the projects are managed, given that most people never meet each other face to face.

Enter Google Summer of Code.

In their FAQ section, Google states that one of the goals of the Summer of Code program is to "inspire young developers to begin participating in open source development." Perfect!

I found the ideal project thanks to one of my school friends (one of the aforementioned die-hards). He knew that I liked graphic design and CorelDRAW, so he suggested that I apply to work on Inkscape, an SVG graphics editor.

My application is online on my portfolio website. I was accepted to work on various improvements to the text tool, which, incidentally, is also what I worked on at Corel during my co-op terms on the DRAW team. I'm really looking forward to getting started and to have the chance to learn more about open source software.

Hopefully throughout the summer project I can post my observations of the open source world through the eyes of a Summer of Code newbie.