Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

 

Methods & Tools - News, Facts & Comments Edition - February 2004

*** Products ***********************************************************

* Open Source Status Wanted for Java

Eric Raymond is the author of "The Cathedral And The Bazaar", a text considered as fundamental for the philosophy of open source development. He recently published an open letter to Sun asking to use the open source model for the evolution of Java. Look at the following reference to see his reasons for this request. It appears however that his understanding of the financial aspect of company evaluation could be improved.

Open letter to Sun: http://www.catb.org/%7Eesr/writings/let-java-go.html

The Cathedral And The Bazaar: http://www.catb.org/%7Eesr/writings/cathedral-bazaar/

*** Numbers ************************************************************

* M&T Poll

With the introduction of the Methods & Tools discussion board, I will try to organise some "quick surveys". This time I ask you how you rate the quality of open source software development tools (examples: Eclipse, MySQL, PHP, Junit, etc...) versus the commercial tools.

Go to http://www.methodsandtools.com/poll/poll.php to express your opinion. The final results will be published in one of our next issue.

*** In Other's Words ***************************************************

* Looking Back to the Future of Open Source

Considering that open source is an obvious success, the most interesting software engineering questions concern open source's future. Will the open-source development approach scale up to programs the size of Windows NT (currently at least four times as large as the largest estimate for Linux)? Can it be applied to horizontal market desktop applications as effectively as it has been applied to systems programs? Should you use it for your vertical-market applications? Is it better than typical closed-source approaches? Is it better than the best closed-source approaches? After a little analysis, the answers will become clear. [...]

The implications of open source's code-and-fix approach might be more significant than they at first appear. By the time Linux came around, requirements and architecture defects had already been flushed out during the development of many previous generations of Unix. Linux should be commended for its reuse of existing designs and code, but most open-source projects won't have such mature, predefined requirements and architecture at their disposal. To those projects, not all requirements and architecture bugs will be shallow. [...]

By largely ignoring upstream defect removal and emphasizing downstream defect correction, open source's methodology is a step backwards - back to Code and Fix instead of forward to more efficient, early defect detection and correction. This bodes poorly for open source's ability to scale to projects the size of Windows NT or to brand-new technologies on which insufficient upstream work can easily sink a project. [...]

The open-source movement has not yet put its methodology under the open-source review process. The methodology is currently so loosely defined that it can hardly even be called a "methodology". At this time, the strength of the open-source approach arises largely form its massive code-level peer review, and little else. For open source to establish itself as a generalizable approach that applies to more than a handful of projects and that rises to the level of the most effective closed-source projects, it needs to fix four major problems:

- Create a central clearinghouse for the open-source methodology so it can be fully captured and evolved.

- Kick its addiction to Code and Fix

- Focus on eliminating upstream defects earlier

- Collect and publish data to support its claims about the effectiveness of open-source development approach

None of these weaknesses in open source's current development practices are fatal in principle, but if the methodology can't be evolved beyond its current kludgy practices, history will record opens source's development approach as a one-hit wonder. If open source can focus the considerable energy at its disposal into defining and using more efficient development practices, it will be a formidable force indeed.

Source: Steve McConnell, "Open-Source Methodology: Ready for Prime Time?", IEEE Software, July/August 1999

We rarely take the time to look to the past in the software development world. I was browsing this old issue of IEEE Software of the last century when I saw this editorial about the open source approach. I must admit that I have a rather "external" vision of the open source movement, because I have never participated to an open source project and I have just begun last year to use some open source software.

I do not want to argue about the success or failure of the open-source approach, also because it could be difficult to compare the current situation with 1999. Since then, there has been a major involvement of the commercial software community in the development of open source software (IBM with apache or eclipse, Sun with open office, Zend with php, ...). I would just like to express some thoughts generated by this text.

The need of a formal, written methodology is often caused by the will to assure the success of an organisation independently of the people involved in the software development process. I think that the situation is very different in the open source movement where I see a strong sense of "product" ownership. In a traditional project, the most interesting thing seems to write the first release. In the majority of the companies I know, people want to work in a project for 6-12 months and then switch to another domain or technical environment to learn something new. Maintenance and evolution are not appealing activities. It seems to me that open source developers have a higher personal involvement. It is true that they can choose the project they want to work with.

Finally, the opens source software that I am using causes no problems which is not always exactly the case when I deal with products from a large commercial software development company that crafted the NT operating system... ;-)

*** Web Siteseeing *****************************************************

* The softer side of hardware

Many computer manufacturers have understood that software is important, at least to sell their boxes. Here is a selection of web-site sections where you could find some information about software technologies like Java, XML or Web services. There are also some free or evaluation software to download.

http://developer.apple.com/

http://devresource.hp.com/drc/index.jsp

http://www-136.ibm.com/developerworks/

http://www.intel.com/cd/ids/developer/asmo-na/eng/index.htm

http://developers.sun.com/

*** M&T News ***********************************************************

* Launch of the Methods & Tools discussion board

A discussion board has been set-up on the Methods and Tools website. Its goal is to improve the communication between readers and allow them to give feedback to the editor and the authors. It will also serve as an announcement board for the software development tools vendors community, a type of information that was not finding its place in the PDF issues or Facts newsletters. I hope that you will it useful. As always, your suggestions to improve this discussion board are welcome. 

Forum URL: http://www.methodsandtools.com/forum/index.html

You will have to register to post on the forums. The registration to the forum is independent of your subscription to Methods & Tools.

----------------------------------------------------------------------

* Coming UP

In the Spring 2004 issue (published at the end of March), we will have articles about Precise Use Cases and Identifying your Organizations Best Practices.

In the Summer 2004 issue (published at the end of June), we will have articles about Branching Strategies in software Development and Management of Open Source Project.

Stay tuned!

===========================================================

The content of this publication cannot be reproduced without prior written consent of the publisher - Copyright (C) 2004, Martinig & Associates

March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
November 2009
October 2009
August 2009
May 2009
April 2009
February 2009
January 2009
November 2008
October 2008
August 2008
May 2008
April 2008
February 2008
January 2008
November 2007
October 2007
August 2007
May 2007
April 2007
February 2007
January 2007
November 2006
October 2006
August 2006
May 2006
April 2006
February 2006
January 2006
November 2005
October 2005
August 2005
May 2005
April 2005
February 2005
January 2005
November 2004
October 2004
August 2004
May 2004
April 2004
February 2004
January 2004
November 2003
October 2003
August 2003
May 2003
April 2003
February 2003
January 2003
November 2002
October 2002
May 2002
April 2002
February 2002
January 2002
November 2001
October 2001
May 2001
April 2001
February 2001
January 2001
Winter 2000
Fall 2000

Software Testing
Magazine


The Scrum Expert