1
edit
Changes
no edit summary
The main purpose of this report is to provide a concise summary of two presentations given at this year's Free Software and Open Source Symposium (FSOSS) as well as highlighting the speaker's view about open source and the surrounding communities in general. In addition, I'll be providing my own views about open source, it's supporting communities, and what I was able to take away from the presentations given at this year's FSOSS. This being my first FSOSS event, I was naturally overwhelmed and somewhat intimidated by all the “big-shots” in the world of open source. I went into this event with one goal in mind - to gain a better understanding of free software and open source and be able to apply what I learned when working on my own open source related projects.
=== Summary ===
I chose to attend the following two presentations because I believed – based on their brief description in the agenda page – that they would provide me with knowledge that I could put to use throughout the development of my own open source project. My own project in particular entails much code reading, code reuse, and is supported by a relatively large Firefox localization community. After much consideration, I knew that the following two presentations, as well as their respective speakers, would best complement my existing knowledge about code reading, code reuse, and developing for communities – while adding an open source “spin” on them. At the end of the event, I knew I had made the correct choice since much of what I learned has been applied to my existing open source project. As a result of the FSOSS event, the development of my open source project has considered the community at every stage in development. For example, when we want to incorporate a new feature, we first ask ourselves if this feature is needed by the localization community and furthermore, will the feature be supported by those who are leading the localization effort at Mozilla.
==== Code Reading and Review ====
Benjamin Smedberg's presentation outlined the reasons for reading code, difficulties encountered when reading code, code reading in a broader sense, and the different types of code review. He mentioned the various reasons why people read code which included – apart from it being an entertaining activity for “geeks” as he put it – fixing a bug, adding features, writing documentation, or just learning how a system works. Benjamin got down to the point and spoke about how code reading is hard especially when it comes to more complex systems. However, he emphasized that code in an open source context is '''not''' an individual activity and is in fact a '''social''' one. Code reading requires the participation of the code's author as well as the experts who contribute, maintain, or use the code extensively. The only exception to this rule would be if the system has no documentation, is relatively new, and the author of the code cannot be reached. The presentation also dived deeper into how to fix bugs by looking for common bad patterns such as “off-by-one” or “unsigned/signed mismatches”. I appreciated the advice he gave about mixing software frameworks together. Benjamin cautioned us that mixing frameworks, especially in JavaScript in particular, can lead to pitfalls in design and quality. In addition, Benjamin stressed that you do not have to understand the entire code, instead, you only need to understand the part of the code that concerns your end objective(s).
Since my own project involves working with an existing localization community I knew that Mike's presentation would give me more insight into how to work with them. The community in my own project is relatively large and is being led by a few Mozilla employees. They have been leading us with structure and organization by providing us with scripts, tools, contacts and possible approaches to reaching our main goals and objectives. In addition, we have also been following Mike's first maxim, listen to your community, by adding and removing features according to what we believe the community would want as well as their direct input through tools such as Bugzilla. Throughout the development of our project, we tried to keep our tool simple and not overly complex to use. We knew that if we made a complex tool, the community would simply reject it and the project would not progress any further in the future. With the help of Mozilla's Axel Hecht and Michal Berman (deeply involved in localization) and support from our professors Dave Humphrey and Chris Tyler - who have helped us considerably by providing us with strong guidance and contacts - we have been able to get our project off the ground and have built the foundation for a tool that the community can put to good use in the near future. We have also had a small taste of the some negative things from the open community. To put it briefly, our project is somewhat dependent on Python scripts and tools already built by Mozilla's localization team as well as the supporting community. Axel Hecht had recommended that we use a particular script to help with a specific feature in our system. For nearly a month and a half we tried to get in contact with the script's owner for information regarding the Python script. We finally got in touch - through Bugzilla - and are in the process of incorporating their tools with our new tool as recommended by Mozilla's localization team. Overall, we learned how to make due with the scripts we had and develop our system.
=== Views on Open Source ===
Both speakers primarily talked about open communities and how leading them can result in greater benefits for open source projects or existing open source products. Although both talks were about different topics, they had similarities when it came to how to manage and maintain an open community. Both talks also provided many tips and tricks on how to use specific products or follow certain methodologies. All speaker's views on open source met my expectations and overall I learned a great deal more about the communities surrounding the open source world.
==== Open Source Views From Code Reading and Review ====
Developers must take into account that when they are writing their code, they should be writing it in a way that will make it simple for another developer to come in an read it and understand it in some ways. They can do this through documentation or other means to communicate the code and design decisions that were made throughout development. By making code easy to read, the authors can take advantage of the vast community that accompanies most open source projects by helping potential developers understand the code so they can attempt to contribute to it in some way. Also, its important for open communities to be able to read the code because most projects will have bugs. Often, the community is the one that will find these bugs and rectify them through patches. Developers must make an effort to make their code easy to read so communities can review the code without stopping at every class or method and asking “why do we need this?”. Open source communities also have a tendency to reuse existing code – something that I'm beginning to understand a great deal about. When you write code, there is always a possibility that your code may be used and adapted to someone else project. Proper documentation can make this adaption easier for the developer and increased the quality of the product.