Changes

To finish off I would say many important points were covered by this speaker; especially the reasons for the reading code, the purpose of reviewing and the constant inference on quality of the code. Documentation was yet another major emphasis made by this speaker and in my opinion I believe this is a very important thing for any coder to practice. Documentations is the only link that other have sometimes when people are trying to understand and decipher some other persons code. Nothing that happened in this talk changed my view of open source or what the entire community is all about. <br> <br>'''Mike Beltzner’s designing for and with community'''<br>I must say I have never attended a speaker’s talk that was filled with so many “weeeeees” and other funny expressions as Mike Beltzner’s talk about designing for and with the open source community. A very intriguing speaker who captivates you with his interest, presentation style and overall funny demeanor; something I think is very attention grabbing for me at the least.<br><br>I remember the first and foremost thing Mike talked about, he said designing in open source is not something that is ready for primetime. I must honestly say at first I had my doubts about what he was referring to in that statement; but then it occurred to me; maybe it is the way of how designing and implementing is done in the open source community drawing parallels to cathedral and the bazaar. In today’s world of organization and control the bazaar type of software development is yet to be embraced by the major corporations and companies; and in my foreseeable future at the least I do not see this trend of developing software changing. Maybe this is what Mike was referring to when he said “Designing in open source is not something that is ready for primetime” I could be wrong.<br><br>One of the major things Mike talked about was embracing the chaos of open source. There are always many different perspectives out there and many different ideas on how people want to help out. Some might just be condescending while others are generally out to help the new comers feel at home. He then went on to talk about the three main points of designing for and with the open source community. They were as follows:<br>*Listen to your community (because if you do not do so, they will get alienated by the lack of listening and therefore grow to hate the product)*Lead your community (setting examples and most importantly standards by which work should be done in is key and very important in this type of open source environment)*Let the community play and experiment (in order to build a strong community support and gain loyalty the company must allow the community to fully take apart and understand the underlying code base of the software. This will allow for people to experiment with their own knowledge and therefore creating their own extensions or add on that can benefit the rest of the community or in some cases even the original creators of the software).<br><br>Mike also pointed out a key point that caught my attention; he said thirty seven percent of code that came into Firefox between November 2006 and April 2007 were from outside contributors and not from within the company developers. He also pointed out certain factors that are part of the open source community and people should learn to accept this. They were as follows:*There are no easy buckets (meaning like every company or organization no one will give you credit right away; credit has to be earned and one has to prove themselves as a worthy contributor)*Strong leadership structure (major contributors and creators of the code should be strong in their leadership of their community otherwise the community will loose strength and support)<br>