User:Anna.sobiepanek/FSOSS 09

Introduction

October 24, 2009 - October 30, 2009 was Toronto Open Source Week, a celebration of Open Source Technology. As part of the celebration, Seneca College hosted the annual Free Software and Open Source Symposium. FSOSS allows members of the Open Source community to come together and share their ideas. More importantly, it allows newcomers to get involved.

Check out the workshops.

Check out the list of presentations.

Fame, Fortune, and Technical Writing by: Dru Lavigne

Dru Lavigne is the Editor-in-Chief of the Open Source Business Resource. She has also written a number of books for O'Reilly. Read more about her

Dru Lavigne talked about making technical writing a career. She pointed out that this is a great time to become a technical writer, as there is 0 barriers to entry. Nowadays you can publish yourself on the web easily, and most often for free. After all, there is always room for more documentation. Dru stated that if you are good, you will get noticed, and you will get paid. But in order to get notices, you have to write and do so daily. When people search for you using a search engine, they should be able to find good examples of your work as well as your followers. Also, you should get involved and collaborate with the community. This includes editors, proof readers, and editors.

Dru Lavigne broke down her talk into Recognition, Inspiration, Publishing, and Earning Money. Here is what she had to say:

Recognition In order to get recognized you have to get your work and name out there through; blogs, book reviews, articles, and How To's. Don't wait until your work is perfect before publishing it on the web, if you do the topic might not be interesting or popular anymore. If you want to be a perfectionist, focus your efforts on making sure your grammar and spelling is flawless, even in your personal blog's. Most importantly, do your research. The information you post must be credible.

Inspiration Write about whatever interests you. There are many things that Open Source projects need like; documentation team members and leaders, man pages, tutorial, and guides for newcomers. You can also write articles and news in mainstream publications, write papers, brochures, and critique artwork or web content. Sometimes you have to change-it-up to get creativity flowing.

Publishing So you want to get published? Publishers want to see that you have a big following, an audience. They also want to know that your expertise is currently 'hot' or popular. Most importantly, they want a well thought out proposal. Write your proposal as if you were gonna start writing your book tomorrow.

Some interesting stuff:

• for technical books 10,000 copies sold makes it a "best seller"
• taking 3 months(50 hrs/week) to write a book is considered fast
• a very small # of books get promoted by mainstream publishers and small publishers have less resources for promotion

Earn Money You have to know what your goal is. Is your writing a hobby, a career, or a means to an end. You should re-evaluate your volunteer to paid ratio every 6-12 months. If you want to make money, you should probably cut down on the volunteer work. If you are entering the field expect to pay you'r dues. This means that you will need to start by writing free reviews.

Dru Lavigne also talked about helping your fellow writers. You can do this by introducing them to editors and publishers. You can invite them to co-write an article or book with you, and even invite them to speak at conferences. I found this talk very interesting, I always tried to minimize my web presence with the mentality that employers don't like seeing drunken facebook photos. I never thought about the amount of free advertising you can get by publishing stuff on the web. It's like volunteering from home.

Ranking the Bugs: Predicting Which Bugs Will Get Fixed by: Diederik van Liere

Diederik is a Post-doc Researcher at the Rotman School of Management (U of T). Diederik has a PhD from RSM Erasmus University which is in the Netherlands.

Diederik's talk was about reporting Bugs at Bugsilla and the process that follows. Check out his blog post Obviously, the first step is reporting a Bug. But what happens after the bug gets reported? Here is the process:

• Every bug that is reported has to be verified. The average time to verify a bug is 3.6 days.
• People leave messages outlining the possible solution for the bug
• The bug gets fixed. Average time to fix a bug is 6.7 days. Mozilla employee's bugs are fixed faster than those of community members.

When you file a bug you need to make sure that your bug report contains all of the important information. The quality of bug reports ranges from 0 to 4, 4 being excellent. This number can be calculated by the sum of the presence of the following items; steps to take to reproduce the bug, a stack trace, a screen shot, and version information. So if your bug report only has the steps to take to reproduce the bug and version information it would get a rating of 2. Higher rating of your bug report, leads to shorter verification time.

The time it will take to fix the bug is dependent on the developers; productivity, efficiency, and skill set. Your bug report can be flawless but if the developer doesn't have the skills necessary to fix the problem, he will need to spend some time researching.

Diederik stated that he considers anyone that posted at least one bug to Bugzilla a community member. He also pointed out that the community is like an information repository(collection of threats, artifacts, and information). Its also a collective group of people that share goals, purpose, and social group. Each community member can build, discuss, and add to the information repository. Understanding whats in the information repository shortens the time it takes to verify the bug. Diederik also talked about community churn; the process of community members leaving and getting replaced by new members. This process reduces the understanding of the information repository. Therefore, retention of community members is key, and getting new members through the learning curve is essential.

Finally, the last topic that Diederik talked about was tools that can help you predict when your bug will be fixed. These tools include:

Jetpack Add-On to Predict Likelihood of Bug Fix in Bugzilla, Crowdsourcing Flamy Firefox Bugreports, and Crowdsurfing Mozilla Developers Handles. Check out Diederik's blog on these tools.

View's on Open Source, Conclusion

Both Dru's and Diederik's views on Open Source were positive. Dru talked about using the community in order to get noticed and also helping your fellow writer's get noticed. Diederik talked about using the communities' knowledge to help with fixing bugs and also getting new comers through the learning curve. Both speakers recognize the potential gold mine (the community). While listening to the presentations, I realized that the Open Source community is filled with people that want to learn and want to teach. It kind of hard to imagine that people actually get paid for doing Open Source stuff, especially since it seems like it's their hobby. I've done full time work before and it's rarely something to be excited about, but all of these presenters were actually excited!

I guess passion and sharing are the major points I took away from this symposium.