FSOSS Report by vlam6

Introduction

Before I begin my report, I think it is best if I give a brief introduction of what is FSOSS. FSOSS stands for Free Software Open Source Symposium. It is an event that happen every year in Seneca@York where people from all over the world gather together and talk about their view on open source, open content, open format which are changing the way everybody work, play and learn. This is my very first time involving in the FSOSS and I find the experience to be extremely rewarding. I strongly encourage everyone who is interested in developing software to attend FSOSS next year. The purposes of this report are to summaries, analysis and make comparison of two talks that I have attended in FSOSS. It is difficult to choose which talk to attend to in the first place, and now it is difficult to choose which two talk to talk about because there are just too many of them. Among all the talks that I have attended, I have decided to focus my report on the following two talks.

1. Code Reading and Review, by Benjamin Smedberg from Mozilla Corporation.
2. Open Commercial Development, by Lawrence Mandel and Jeffrey Liu from IBM Canada

I picked the talk on Code Reading and Review because I have been code reading and reviewing for years. I find a lot of strategy on code reading and reviewing Benjamin talked about is similar to what I have been using and I picked the talk on Open Commercial Development because I would like to learn more about the IBM insight of open source development and find their insight to be completely different from what I believe in.

Summary

Code Reading and Review

I chose to attend to this talk because I really want to learn about how to read and review better as code reading and review is essential to any coding and debugging process. Especially when I am taking Open Source Project (DPS907), I am hoping I would learn something which I can apply directly to my open source project on localization. His presentation involved materials such as fixing a bug, fixing a feature, reading, writing and using documentation, difficult of code reading and reviewing, how to get detail, how to use lxr, tools that he uses such as grid and find, software framework, version control tool, how to look back in time, where to find and how to talk to an expert, goal of code reviewing, API/design, maintainability, security, UI, integration, testing review, how to form/involve in an open source community, how to invite people to your community, how to decide if the code is worth reviewing or reusing, and the important listen to the community but take the leadership. I have been doing code reading and review for years but I never asked myself why I am reading and reviewing code, but his point of view of why we are code reviewing amazed me. Some of the points he made are somewhat similar to why I have been code reading. I have been using lxr and mxr to tract down the source code I need. When I found a problem in my program and I need to fix it, therefore I am reading my code; bug fixing. I find it difficult to figure how the source code works and I am angry about it because there is no documentation; document code. I have been using grid, find and debugger to debug, read and review code because they are the simplest way to tract down a variable or function. I can really relate to the strategy that he uses in code reviewing, but the above strategy has nothing to do with the open source community. How is code reading and review different in an open source project? Open source is about community, it is about how everyone works together in an open environment when source code and ideas are being shared. This is the best and quickest way to chase down a problem and improve security because there can be thousand of people looking at the same problem at the same time and there can be thousand of people trying to break or fix the code. Open source project can improve something quickly but it is very difficult to control and this cost maintainability problem. Once a source code got published, there can be hundred of people trying to make a new patch for the code. There is a need in maintaining and controlling new patches. Program such as CVS and CVN can be useful in this case. They allow user to view any previous version of the code therefore, if anything went wrong they can always rollback.

Open Commercial Development

This presentation consists of two parts:

• Open Source definition and licensing
• Open Commercial Development.

The first part of the presentation is generally, highlighting the open source definition from the internet such as opensource.org, microsoft.com, etc. They highline some of the key definition such as: free redistribution, project must include source code, derived works, integrity of the author’s source code and distribution of license.

The second part of the presentation is suppose to be about open commercial development, which is suppose to be a new hybrid development model that takes aspects of both the open and proprietary development models to provide a new model for the commercial software development process as defined in the symposium event description but based on what I understand from the talk, open commercial development is not a new development model that is created by IBM. Instead, it is an old development modal that has failed many times based on historic facts. The word, “open” in open commercial development is extremely misleading because open commercial development is not open source. Basically, open commercial development is a transparent development process for which they get user to participate when they are developing new software. In general, they are trying to apply open source technical to development as oppose to what they usually use a “closed” development modal. By applying the open source technical, they are trying to get direct customer involvement into project in order to improve software quality. I find the material and strategy which they have presented to be very similar to the agile development technique and they are trying make money out of the free direct customer and open source community input without crediting the contributor.