Summary for readings on June 28th

[1] presents results form an empirical study of OSS developers' opinions about usability and the way usability engineering is practiced in a variety of contemporary OSS projects:

“to understand current practices and obstacles to change”
“focus on projects carried out by small groups of volunteer”

Study in [1] consists of 3 element: "(1) an online questionnaire survey answered by contributors to a variety of OSS projects, (2) interviews with three OSS developers and (3) interviews with five usability evaluators for OSS projects."
Questionnaire consisted of 3 parts: ‘About your current project’, ‘Commu-nication’ and ‘Usability’. The questionnaire quantitative data collected was organized in sections reflecting the 3 focus areas of the questionnaire.
The developer Interviews was preformed with 3 of the respondents (2 project managers and 1 usability tester) from the questionnaire survey. This interview investigated the following themes:

• Respondent’s motivation for contributing to OSS
• Usability considerations used in the project
• Frequency and place of usability evaluations
• Usability as a part of the development process
• Usability experts in the development team
• Willingness to alter program code because of usability problems discovered in tests
• Decision making in the project, especially regar-ding usability

To analyse the data collected in the interviews:

"First we identified a number of topics or tendencies we found impor-tant in the transcriptions. Following this, we analyzed the statements in more detail to extract the overall opinion of the respondent."

Finally, the evaluator Interviews are involved 5 employees at Relevantive who had experience in OSS development and usability engineering. This interview investigated the following themes:
The evaluator interviews are conducted in the following procedure:

• Test procedures of OSS
• Usability evaluation
• Communication with OSS developers
• K Desktop Environment (KDE) guidelines
• Remote usability evaluation
• OSS and usability in general

Following the above procedure, they had conducted personal interviews with 2 employees:

“For these interviews we did not use a pre-constructed interview guide, but instead we used the data collected from the focus group interview to find themes to explore further. Third, we had the opportunity to observe them while they conducted a usability test of an OSS product.”

The data collected in the evaluator interviews was analysed the same way as data in the developer interviews.
By analysing the collected data, [1] has shown the reasons why people are motivated to contribute to OSS:

“In the questionnaire answers, 88% of the developers chose ‘To strengthen free software’ as their motivation,…, and the interviews with developers and usability professionals supported this. In addition, 54% of the questionnaire respondents choose ‘Community reputation’ as a motivation….75% of the developers contribute to OSS in order to improve their skills and 88% wanted to be intellectually stimulated.”

[1] states that “83% of the questionnaire respondents regarded the importance of usability as either ‘high’, ‘very high’, or ‘extremely high’. Only 13% considered it ‘moderate’, 4% stated ‘slight’ and nobody though it had no importance,…”
The study shows that OSS developers have different definition of “usability” too. In addition, OSS developers also had shown reluctance working with usability experts even though they wanted a higher degree of usability in their software.

OSS development process is characterized by short iterative cycles consisting 4 main stages: “In the beginning”, “Iteratively”, “In the end”, and “During testing”. And the OSS developers had different ideas on when usability belonged in the development process.

This paper also suggests that trust relationship is required between OSS developers and usability experts prior the cooperation between the two:

“For instance Relevantive experienced that almost all problems faced when working with OSS developers were grounded in lack of trust, which made developers ignore suggestions from usability professionals.”

OSS projects in general had flat, and organizational structures OSS development is always democratic while the traditional development process is led by a formal leadership:

“…even though almost every OSS project had at least one project manager associated, this title did not imply leadership over the project. Often this title reflected the person who founded the project rather than the person who kept track of everything or delegated tasks to other contributors.”

[1] states 3 common mantras about OSS:

- OSS development is always democratic
- OSS will solve the ‘software crisis’
- Usability problems are just bugs

[2] is intended to answer the following questions:

• How do open source developers define and conceptualize the notion of usability?
• What motivations do FOSS developers have for creating software that is usable by people other than themselves?
• What are current usability practices in the FOSS community?
• How do FOSS usability practices differ from traditional usability practices?

The interview process in [2] consists of the following segments:

“1. Obtaining basic background information on the participant, such as their day job and what FOSS project they are associated with
2. Learning how and when they got involved with their FOSS project. If they were a project member, we also asked what they do in the project and why they stay involved
3. Their perception of the concept of “usability”
4. How they practice or perceive others practicing usability in the project”
One interesting thing to be noted is that the interview participants could define “usability” anyway they want during the interview:
“As can be seen, the definitions of usability span the range of definitions commonly found in the HCI textbooks, and demonstrate that the community, as a whole, possesses a fairly sophisticated, well-rounded notion of the concept.”

There are a number of ways to improve the usability such as interactions between developers and end-users. Tool such as IRC and mailing lists are the communication channels between developers and end-users. However, user does not explain the problem thoroughly and makes it really hard for the developer to help.
Developers do not really use the application they built. The feedback from the user community and the application tests are important to build more stable version of the application.
Usability experts need to educate FOSS project members “about how to think about and practice usability/UX on a day-to-day basis” when they join the FOSS projects.
Social relationships between usability experts and developers serve as primary motivators for addressing usability issue on a day-to-day basis.
The software user size and praise and positive feedback from the users are what motivating the OSS developers to look into the usability issue.
[2] finalizes that the usability and HCI of OSS applications can be improved in the following 2 perspectives:

- Improving Practices from within the FOSS Community
- Reconceptualizing HCI for FOSS Development

REFERENCE
[1] http://itc.ktu.lt/itc353/stage353.pdf
[2] http://doi.acm.org/10.1145/1753326.1753476
[3] http://doi.acm.org/10.1145/1753326.1753576

Summary for readings on June 23rd

[1]'s title is "Exploring Usability Discussions in Open Source Development". [1] talked about usability issues within bug report mechanism in current OSS projects. Study on OSS development has shown the importance of data available in public software repositories and bug database but has paid little attention on data management. [1] has preformed quantitative analysis on the Greenstone mailing lists and the Bugzilla instances at Mozilla and GNOME. The study is looking for answers of the following questions:

What is the nature of usability discussions in OSS projects?
Is it different from what might be expected from the textbooks on how to do interface design?
Is it different from commercial software design?
What are the patterns of discourse and process that emerge within and across projects?

The study in [1] is exploring the bug databases for terms such as ‘usability’, ‘human computer interaction’, ‘interface’ etc. Author assumed that "bug reports that contained those words and were determined to be indeed about usability" and is to be investigated.
The bug report mechanism such as Bugzilla studied in [1] has shown a number of drawbacks:

"sometimes even a screenshot is not sufficient to uniquely identify the problem."
"...bug reports can reveal information about the reporter and the reporter here has clearly gone to significant trouble to obscure the text whilst still reporting the bug."

Rewording text elements of interfaces occurs relatively frequently:

"-Many usability problems can be addressed quickly and cheaply by rewording."
"-In our experience of teaching usability, it is a context where relative usability novices can play a useful role, serving an apprenticeship before moving to more complex problems."
"-Talking about the wording of interface elements is much easier to do in a mostly text based interaction medium such as Bugzilla than talking about graphical elements or interaction processes."

While fixing bug according to the bug report, the developer must avoid “ripple effect”. Ripple effect of bug fixing is demonstrated with the example of “dialog box” problem:

“In fixing this bug, it creates or accentuates other bugs; dialog boxes whose information no longer fits within the pane. Resizable dialog boxes had been used as a workaround for this problem, although one that various commentators to bug A saw as rather clumsy. The consequence was that fixing one bug created the need to fix other bugs.”
“Subjective usability bugs may need a more provisional approval process, while more evidence is collected of the relative incidence and severity of the bug….a duplicate identification tool would be a valuable addition to OSS projects.”

Bug reporting and classification are important to the OSS development:

Reporting tools that automatically provide contextual metadata further reduce the effort required by bug reporters. Subjective usability bugs may need a more provisional approval process, while more evidence is collected of the relative incidence and severity of the bug. Use of suitable keywords could distinguish provisional subjective bugs from more objective established bugs. That would enable investigation to continue without adding undue complexity to the system, and avoid premature discarding of a partial bug report.

Our analysis supports this suggestion and we note that such a tool's effectiveness is partially based on bug metadata. Tools such as GNOME Bug Buddy and the Bugzilla Helper promote structured textual reports but the clarification dialogues shown in Figures 1 and 3, and in numerous bug discussions, show that metadata is more valuable. Bug metadata more directly supports querying and partitioning of the bug reports, which should help to reduce duplicates and parallel bug discussions. Classifying any bugs is a complex process

However, classifying bugs (both usability bugs and functionality bugs) is a complex process:

One approach to classifying usability bugs may be to use the structure of the user interface itself as a hierarchical classification system. That is, the menus, sub-menus and dialog boxes of the interface become nodes in the classification hierarchy of the bug repository, so that a preferences bug can be located directly from the system's interface.

Bug report management to improve usability is a difficult task. [1] has described the research usability problem with specific key words in the database, but people, especially the non-technical people, can use different wording to describe the same problem without mentioning ‘usability’, ‘human computer interaction’, and interface’.

[2] is titled "Silver bullet or fool's gold: supporting usability in open source software development". [2] is a abstract by Twidale, who is one of the author of [1]. This abstract is about Twidale’s talk on the problem of creating usable interfaces for non-technical end-users. In this talk. Twidale is suggesting a coordination of end-users and developers in order to improve the OSS usability.

REFERENCE
[1] http://dx.doi.org/10.1109/HICSS.2005.266
[2] http://doi.acm.org/10.1145/1062455.1062468

Summary for readings on June 21st

[1] uses Mozilla as subject for usability study, and the user contributions to the Mozilla bug repository into 3 major sections:

1) Separating contributors into four categories of core and active developers, reporters, and users.
2) Analyzing the outcomes of reports written by different contributor groups.
3) Analyzing user and reporter comments in both routine and contentious reports, and developers responses."

[1] performs study in 3 group in the CORE developers, ACTIVE developers, and REPORTERs. Interesting trends are shown in the course of Mozilla development:

"Figure 1 shows the number of contributors commenting every six months since Netscape released their source code in March 1998. Several things are evident from this graph. First, the USER and REPORTER groups are the only groups that fluctuate substantially in their contributions over time; the CORE and ACTIVE developers, in contrast, wrote a comparable number of comments each six months..."

There are 8 types of report resolutions:

fixed reports lead to a change in the software (a patch); incomplete reports are missing data needed to fix an issue; invalid reports identify a problem, but not one that Mozilla was responsible for fixing; worksforme reports did not involve a problem; wontfix reports identify issues that the community decided not to address; and duplicate reports regard issues that have already been reported. We omit the expired and moved resolutions from our analyses, since they were used infrequently."

And,

About 62% of ACTIVE reports and 60% CORE reports are marked fixed, and these account for 79% of all fixed bugs. In contrast, 13% of REPORTER reports are marked fixed, accounting for 21% of fixed reports....Fixed REPORTER reports were also open significantly longer than ACTIVE and CORE reports (RS χ2(df=3,n=148,902) =15,854,p<.0001). The median fixed REPORTER report was open for 371 days whereas the median fixed ACTIVE report was open for 123 and CORE was 119.

[1] also shows that reporter contributions are less frequent, less useful:

the number of REPORTER reports has been dropping since the 0.1 release of Firefox, and the number of fixed reports has dropped with it. In Figure 4, we see that the proportion of REPORTERs’ report resolutions have stabilized, except for an increase in invalid and incomplete reports after the release of Firefox 1.0. In Figure 5, we see that the proportion of fixed reports due to REPORTERS reached its peak with the release of Firefox 1.0, and has dropped since. In fact, of REPORTERS fixed reports, 69% were fixed before the Firefox 1 release.

There are some possible causes to these trends:

..., perhaps most REPORTER effort before the release of Firefox 1.0 was from technically skilled REPORTERS, enthusiastic about the first release of the browser, but after this, less technically skilled REPORTERS dominated the reporting class, leading to more incomplete and invalid reports and fewer fixed reports. It is also possible that those REPORTER reports that would have been marked fixed began being marked duplicate instead, as ACTIVE developers became better at finding and reporting problems before REPORTERS reported them. Another interpretation is that as Mozilla software improved, there were fewer issues to report,...

[2] examines how the open source development process influences usability and suggests usability improvement methods that are appropriate for community-based software development on the Internet There are 5 charactors to describe usability, namely "ease of learning, efficiency of use, memorability, error frequency and severity, and subjective satisfaction and from other characteristics such as reliability and cost.".
Study has been done by comparing OSS and proprietary software, but the following differences between the two might influence such comparisons:

development time, development resources, maturity of the software, prior existence of similar software etc. Some of these are factors are characteristic of the differences between open source and commercial
development but the large number of differences make it difficult to determine what a ‘fair comparison’
should be.

[2] presents a set of features of the OSS development process that appear to contribute to the poor usability problem:

1. Developers are not users
2. Usability experts do not get involved in OSS projects
3. The incentives in OSS work better for improvement of functionality than usability
4. Usability problems are harder to specify and distribute than functionality problems
5. Design for usability really ought to take place in advance of any coding
6. Open source projects lack the resources to undertake high quality usability work
7. Commercial software establishes state of the art so that OSS can only play catch-up
8. OSS development is inclined to promote power over simplicity

[2] suggests the followng approaches to improve OSS usability:

Commercial approaches
Technological approaches
Academic involvement
Involving the end users
Creating a usability discussion infrastructure
Fragmenting usability analysis and design
Involving the experts
Education and Evangelism

[3] is a blog post written by Professor Terry titled “How Open Licenses Affect User Experience”. The open license leads 4 user experiences such as “Greater choice and variety in software for end-users”, “New types of workflows”, “Software as a communication medium” and “Increased collaboration”.
The 1st user experience is the “greater choice and variety in software for end-users”. Open licenses lead to more software choice via “forking and customization”, “enabling libraries”, and “never dying”. Open licenses lead to variety is through forking and customization. Enabling libraries lead to more choices for end-users, and, as a result, it is easier to create different application serving the same underlying goal. Open source applications tend to live on even if their maintainers leave the developments.
FOSS is in the disadvantage while users are making a choice between FOSS and commercial software. First at all, since FOSS is not priced as commercial is, users tend to think that the FOSS is worthless as FOSS is given away for free. Secondly, users tend to expect the commercial software producer to improve its software for a while to continue to make money, and they think the future for open source software is less certain. Finally, since users are not making monetary investment in the software, they are less attached to the FOSS software and more likely to access superficial features of the software. Thus, the FOSS developer must provide the following:

”make a compelling, intuitive, easy-to-use first-run experience so users stick around long enough to learn how to use the software.”
“…tools that help users explore and understand the many alternatives.”

The 2nd experience is the “new workflows”, and this experience consists of 3 modes, namely “the temporary domain expert”, “A La Carte Computing, and the Trivial Use of Fat Apps”:

“The temporary domain expert becomes enough of an expert in a domain to solve a given problem, then moves on to solve other problems.”
“In this mode (A La Carte Computing) of working, what is important is the task, not the tools. In this view of computing, people want to get a job done, they want to get it done fast, and they don’t care what tools are required to complete the task.”
“In this case (The Trivial Use of Fat Apps), users under-utilize a powerful, sophisticated application to accomplish a very small task.”

The 3rd experience is “Software as a communication medium” where FOSS is quickly becoming a delivery medium for information, education, and ideas that are interactive:

There are several design implications for this use of FOSS. First, there is a need to be able to quickly install applications so users can focus on the concepts being communicated. Second, there is a need for sandboxes to run untrusted third-party code. Sandboxes have received limited attention in the FOSS community, but will be of increasing importance to support this practice and others, such as collaborative work.

The 4th experience is “Increased collaboration”:

Independent of web apps and applications with built-in support for collaboration, software released under free/open source licenses will lead to greater collaboration between individuals. This increased collaboration is made possible by the ability to freely redistribute a common toolset for performing work.

REFERENCE
[1] http://portal.acm.org/citation.cfm?doid=1753326.1753576
[2] http://www.cs.waikato.ac.nz/~daven/docs/oss-wp.pdf
[3] http://hackingusability.wordpress.com/2010/02/26/how-open-licenses-affect-user-experience/

Summary for readings on June16th

The topic of reading set on June 16th is on “Usability and Open Source”. [1] is an initial proposal of HCI proposal to the OSS community. HCI offers methods to agree on processes, an appreciation of principles, standards, guidelines within which to develop interfaces that human will have to use.
Human Computer Interaction (including usability engineering and interaction design) offers open source software development at least three important opportunities:

to create systems that are usable by ordinary people
to assure that OSS behaves consistently no matter who contributes to it, and
to respect the needs of disabled users as we standardize visual and interaction interface elements to meet accessibility requirements

[2] claims that OSS’s have poor user interfaces. [2] has stated the challenges within the a number of OSS projects, namely NetBeans, GNOME, and OpenOffice.org. These OSS project are sharing the similar challenges such as communication problem between the geographically distributed OSS project developers. The goal of the HCI professionals is the following:

[…] defining and integrating a suitable usability methodology into open source processes should be the first priority. It is also vital for each project to agree on its target audience, and to specify a clear and preferably centralized decision-making process.

[3] has stated 9 reasons why OSS has poor use interface:

1. Dedicated volunteer interface designers appear to be much rarer than their paid counterparts — and where they do exist, they tend to be less experienced (like yours truly).
2. First corollary: Every contributor to the project tries to take part in the interface design, regardless of how little they know about the subject. And once you have more than one designer, you get inconsistency, both in vision and in detail. The quality of an interface design is inversely proportional to the number of designers.
3. Second corollary: Even when dedicated interface designers are present, they are not heeded as much as they would be in professional projects, precisely because they’re dedicated designers and don’t have patches to implement their suggestions.
4. Many hackers assume that whatever Microsoft or Apple do is good design, when this is frequently not the case. In imitating the designs of these companies, volunteer projects repeat their mistakes, and ensure that they can never have a better design than the proprietary alternatives.
5. Volunteers hack on stuff which they are interested in, which usually means stuff which they are going to use themselves. Because they are hackers, they are power users, so the interface design ends up too complicated for most people to use.
6. The converse also applies. Many of the little details which improve the interface — like focusing the appropriate control when a window is opened, or fine-tuning error messages so that they are both helpful and grammatical — are not exciting or satisfying to work on, so they get fixed slowly (if at all).
7. As in a professional project, in a volunteer project there will be times when the contributors disagree on a design issue. Where contributors are paid to work on something, they have an incentive to carry on even if they disagree with the design. Where volunteers are involved, however, it’s much more likely that the project maintainer will agree to add a user preference for the issue in question, in return for the continued efforts of that contributor. The number, obscurity, and triviality of such preferences ends up confusing ordinary users immensely, while everyone is penalized by the resulting bloat and reduced thoroughness of testing.
8. For the same reason — lack of monetary payment — many contributors to a volunteer project want to be rewarded with their own fifteen pixels of fame in the interface. This often manifests itself in checkboxes or menu items for features which should be invisible.
9. The practice of releasing early, releasing often frequently causes severe damage to the interface. When a feature is incomplete, buggy, or slow, people get used to the incompleteness, or introduce preferences to cope with the bugginess or slowness. Then when the feature is finished, people complain about the completeness or try to retain the preferences. Similarly, when something has an inefficient design, people get used to the inefficiency, and complain when it becomes efficient. As a result, more user preferences get added, making the interface worse.

[4] begins with 2 of Free Software’s usual problems:

1. Weak incentives for usability
Solution: Solutions: Establish more and stronger incentives. For example, annual Free Software design awards could publicize and reward developers for good design.
2. Few good designers
Solutions: Provide highly accessible training materials for programmers, and volunteer designers, to improve the overall level of design competence.
3. Design suggestions often aren’t invited or welcomed.
Solution: Establish a process for usability specialists to contribute to a project.
4. Usability is hard to measure.
Solutions: Promote small-scale user testing techniques that are practical for volunteers.
5. Coding before design.
Solution: Pair up designers with those programmers wanting to develop a new project or a new feature.
6. Too many cooks.
Solution: Projects could have a lead human interface designer, who fields everyone else’s suggestions, and works with the programmers in deciding what is implementable.
7. Chasing tail-lights.
Solution: Encourage innovative design through awards and other publicity.
8. Scratching their own itch.
Solutions: Establish a culture of simplicity, by praising restrained design and ridiculing complex design.
9. Leaving little things broken.
Solution: When scheduling bug fixes, take into account how long they will take, possibly scheduling minor interface fixes earlier if they can be done quickly.
10. Placating people with options.
Solution: Strong project maintainers and a culture of simplicity.
11. Fifteen pixels of fame.
Solutions: Provide alternative publicity, such as a Weblog, for crediting contributors.
12. Design is high-bandwidth, the Net is low-bandwidth.
Solutions: Develop and promote VoIP, video chat, virtual whiteboard, sketching, and animation software that allows easier communication of design ideas over the Internet.
13. Release early, release often, get stuck.
Solution: Publish design specifications as early as possible in the development process, so testers know what to expect eventually.
14. Mediocrity through modularity.
Solution: Design an example graphical interface first, so that interface requirements for the lower levels are known before they are written.
15. Gated development communities.
Solutions: Free Software system vendors can coordinate cross-component features like this, if they have employees working on all relevant levels of the software stack.

[5] states the following questions the GUI application developer for Linux or BSD should ask to herself:

1. What does my software look like to a non-technical user who has never seen it before?
2. Is there any screen in my GUI that is a dead end, without giving guidance further into the system?
3. The requirement that end-users read documentation is a sign of UI design failure. Is my UI design a failure?
4. For technical tasks that do require documentation, do they fail to mention critical defaults?
5. Does my project welcome and respond to usability feedback from non-expert users?
6. And, most importantly of all...do I allow my users the precious luxury of ignorance?

[6] claims that OSS should be task-oriented instead of feature-oriented. A task-oriented configurator would have logic in it like this:

•If the machine doesn't have an active LAN interface, gray out all the "Networked" entries.
•If the machine has no device connected to the parallel port and no USB printers attached, gray out the "Locally connected" entry.
•If probing the hosts accessible on the LAN (say, with an appropriately-crafted Christmas-tree packet) doesn't reveal a Windows TCP/IP stack, gray out the SMB entry.
•If probing the hosts accessible on the LAN doesn't reveal a Novell Netware NCP stack, gray out the NCP entry.
•If probing the hosts accessible on the LAN doesn't reveal a Jet-Direct firmware TCP/IP stack, gray out the JetDirect entry.
•If all Unix hosts on the LAN have CUPS daemons running, gray out the LPD entry.
•If the preceding rules leave just one choice, so inform the user and go straight to the form for that queue type.
•If the preceding rules leave no choices, complain and display the entire menu.

REFERENCE
[1] http://doi.acm.org/10.1145/506443.506666
[2] http://doi.acm.org/10.1145/985921.985991
[3] http://web.archive.org/web/20030201183139/http://mpt.phrasewise.com/discuss/msgReader$173
[4] http://mpt.net.nz/archive/2008/08/01/free-software-usability
[5] http://catb.org/~esr/writings/cups-horror.html
[6] http://catb.org/~esr/writings/luxury-part-deux.html
[7] http://daringfireball.net/2004/04/spray_on_usability

Summary for readings on June 14th

[1] describes the social behavior in OSS team and development of the OSS browser which helps to observe the social network in OSS team.
A lot of studies focus static accounts of OSS community organization which views OSS community as a role hierarchy. Starting from the top of the hierachy, there are core developers, maintainers, patchers, bug reporters, documenters and then users. Core developers often have the smallest population but hold very important role in the community:

Indeed several empirical studies have found that, in a large majority of cases, a small core group is often responsible for a large proportion of the work accomplished and a very large group of peripheral participants is responsible for the remainder.

However, there are still less studies on volunteer's motivation to participate the OSS project while there are more studies in the OSS community structures. Motivation starts from socialization of newcomers, which is an important ingridient to keep the project going. OSS community relies on online tools as "a central source of power and influence". However, the centralized online tools would face the follwoing problems:

First, and especially for those interested in using qualitative methods, it is extremely easy to fall prey to data overload. Indeed the number of messages exchanged in Open Source mailing lists is in the order of hundreds, frequently thousands of messages per week....Second, OSS research material can be quite opaque. Despite their centrality in the Open Source development process, tools such as CVS databases, for example, produce few immediately analyzable outputs to the untrained eye.

To analyse OSS project, the author has started OSS Project Browser project to study and analyse OSS movement. The author has proposed 2 theorietical attributes:

(1) The software must make the hybrid nature of a project visible by showing
the connections not only between people, but also between people and material artifacts.
(2) The software must offer a dynamic perspective on activities and allow observations over time."
The OSS Project Browser should facilitate the ethnographic observation of a OSS project:
(3) It must offer both aggregate views (to avoid data overload and facilitate the selection of interesting episodes of activity) and at the same time preserve access to the raw, untouched research material for qualitative analysis.
(4) Since my interest here is in the socialization of newcomers, there must be ways to track a participant’s trajectory easily.

The author experiments the OSS Project Browser with Python, and the following description explains how the OSS Project Browser works:

The topmost pane (1) is a graphical representation of (borrowing Latour’s (1987b) terminology) the hybrid network for a particular OSS project. Black dots are individual participants in the project. A black line connects participants if they have both responded to each other over email. The more they reciprocated, the shorter the line (as in Sack, 2001). Another important part of this representation consists of the artifacts for this project, namely software code. Code is represented as blue rectangles. When an individual contributes code to the project, he is connected to the corresponding artifact with a blue line. The more he contributed to this particular artifact, the shorter the line.

From the study in “Fred” case, the process to reach the status of developer in Python involves the following steps:

(1) peripheral monitoring of the development activity;
(2) reporting of bugs and simultaneous suggestions for patches;
(3) obtaining CVS access and directly fixing bugs;
(4) taking charge of a ‘‘module size’’ project;
(5) developing this project, gathering support for it, defending it publicly;
(6) obtaining the approval of the core members and getting the module integrated into the project’s architecture.

Identity establishing is important for one to become a developer:

First, one can actively contribute to PEPs and features discussion….Second, one can submit bug reports and, simultaneously (this is important), a proposed solution to fix these bugs.

The OSS browser can help the new participant in the following steps:

(1) A period of ‘‘lurking’’ to assimilate the project’s culture and identify the areas in need of new contributions.
(2) Enrollment of key allies in support of future work.

To summarize this paper, author lists the following limitations in Open Source research:

Open Source projects are dynamic entities, yet most of the current research has produced only static accounts of their activity.
Open Source projects are hybrid, multi-sited environments composed of a network of human and material artifacts, yet these dimensions are often considered in isolation.
The massive amounts of research data available tend to favor aggregate statistical analysis to the detriment of more qualitative, in-depth analysis of the activity in a project.
Open Source productions are often difficult to understand for non-developers; accessing and processing some of this data (e.g. CVS records) requires technical knowledge.

The author proposed 2 frameworks to understand sodialization in Open Source projects:

(1) as an individual learning process based on the construction of identities, and
(2) as a political process involving the recruitment and transformation of human and material allies.

In conclusion, the new comer needs to earn his identity and trust from the core developer in order to gain the full access to modify the source code. I think this makes sense in the way that it is logically the new comer needs to go through all the process to add one piece of code in the source code. In this way, the new code is bullet-proof and this will reduce the rate or error in the source code.

REFERENCE
[1] Ducheneaut, N. 2005. Socialization in an Open Source Software Community: A Socio-Technical Analysis. Comput. Supported Coop. Work 14, 4 (Aug. 2005), 323-368. http://dx.doi.org/10.1007/s10606-005-9000-1

Summary for readings on June 9th

[1] [2] studies the following areas:

1. why individuals participate
2 resources and capabilities supporting development activities
3. how cooperation coordination, and control are realized in projects
4. alliance formation and inter-project social networking
5. FOSS as a multi-project software ecosystem
6. FOSS as a social movement

Free software generally appears licensed with the GNU General Public License (GPL), while OSS may use either the GPL or some other license that allows for the integration of software that may not be free software. Free software can be seen as a social movement, whereas OSS is just a software development methodology,...

Participates join the FOSSD projects for various reasons:

Sometimes they may simply see their effort as something that is fun, personally rewarding, or provides a venue where they can exercise and improve their technical skill or competence in a manner that may not be possible within their current job or line of work....building trust and reputation, achieving "geek fame", being creative, advancing through evermore challenging technical roles,...

The following are the resources needed to help make FOSS efforts more likely to succeed:
Personal software development resources: Volunteers participates the project via Internet and they can bring their development methodologies to the project.
Beliefs supporting FOSSD: Beliefs are freedom of experession and freedom of choice.

in FOSS projects, these additional freedoms are expressed in choices for what to develop or work on , how to develop it, and what tools to employ. They also are expressed in choices for when to release work products, determining what to review and when, and expressing what can be said to whom with or without reservation.

FOSSD informalisms: the information the participants use to describe, proscribe, or presecribe what is happening in a FOSSD project.

(i) communications and messages within project Email lists, (ii) threaded message discussion forums,
bulletin boards, or group blogs, (iii) news postings, (iv) project digests, and (v) instant messaging or Internet relay chat. They also include (vi) scenarios of usage as linked Web pages, (vii) how-to guides, (viii) to-do lists, (ix) FAQs, and other itemized lists, and (x) project Wikis, as well as (xi) traditional system documentation and (xii) external publications. FOSS (xiii) project property licenses are documents that also help to define what software or related project content are protected resources that can subsequently be shared, examined, modified, and redistributed. Finally, (xiv) open software architecture diagrams, (xv) intra-application functionality realized via scripting languages like Perl and PHP, and the ability to either (xvi) incorporate plug-in externally developer software modules, or (xvii) integrate software components, modules, or scripts from other OSSD efforts

Competently skilled, self-organizing and self-managed FOSS developers: Volunteers require a base of prior experience in constructing open systems and experience in project management fools.
Discretionary time and effort of FOSS developers: Participants contribute their time and effort to the project because of various reasons:

self-determination, peer recognition, project affiliation or identification, and self-promotion, as well as belief in the inherent value of free software.

Trust and social accountability mechanisms: Developing FOSS source code and applications requires trust and accountability among project participants.
Software version control tool is required to resolve conflicts in the course of FOSS development, and this tool has the following elements:

(a) a centralized mechanism for coordinating and synchronizing FOSS development...
(b) an online venue for mediating control over what software enhancements, extensions, or architectural revisions will be checked-in and made available for check-out throughout the decentralized project as part of the publicly released version

Many FOSSD projects are interdependent through the networking of software developers, development artifacts, common tools, shared Web sites, and computer-mediated communications.

REFERENCE

[1] Scacchi, W. 2007. Free/open source software development. In Proceedings of the the 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (Dubrovnik, Croatia, September 03 - 07, 2007). ESEC-FSE '07. ACM, New York, NY, 459-468. http://doi.acm.org/10.1145/1287624.1287689

[2] Scacchi, W. 2007. Free/open source software development: recent research results and emerging opportunities. In the 6th Joint Meeting on European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering: Companion Papers (Dubrovnik, Croatia, September 03 - 07, 2007). ESEC-FSE companion '07. ACM, New York, NY, 459-468. http://doi.acm.org/10.1145/1295014.1295019

[3] Ye, Y. and Kishida, K. 2003. Toward an understanding of the motivation Open Source Software developers. In Proceedings of the 25th international Conference on Software Engineering (Portland, Oregon, May 03 - 10, 2003). International Conference on Software Engineering. IEEE Computer Society, Washington, DC, 419-429.

Summary for readings on June 2nd

Reading theme of June 2nd is about processes of Apache project and Mozilla project.
[2] is is about Apache project. Since the Apache Group members are working in geographically decentralized work spaces, all information on Apache Group is recorded three archival sources of data, namely Developer email list (EMAIL), Concurrent Version Control archive (CVS), and Problem Reporting Database (BUGDB).
Apache Project team began by solve the process issues first before the development began, because:

"..it was clear from the very beginning that a geographically distributed set of volunteers, without any traditional organizational ties, would require a unique development process in order to make decisions."

Apache Group member sets requirement for people who are interested in Apache developement:

"Each Apache Group (AG) member is volunteer who contributed for extended period of time..., and are nominated for membership and then voted on by existing members."

The AG member has the privrige to "vote on the inclusion of any code change, and has write access to CVS". A "core developer" is active in 4-6 developments in any given week. Each Apache developer iterate the following action through the course of Apache development:

"...discovering that a problem exists, determining whether a volunteer will work on it, identifying a solution,k developing and testing the code within wheir local copy of the course, presenting the code changes to the AG for review, and committing the code and documentation to the repository"

When an AG member has discovered a problem in the development, the AG member can report it in EMAIL, BUGDB and the USENET Apache newsgroups. Then, developer, who has experience to specific type of problem, will be a volunteer to work on the problem. Noted that "developers tend to work on problems that are identified with areas of the code they are most familiar." The Apache is divided into parts and the developers are assigned the "code ownership" of parts of the server that they are know to have created or to have maintained consistently. Developers can forward their possible solutions to the mail list for group to review in order to develop the solution. Once solution is identified, the developer tests and makes the changes to the Apache source code. Noted that “…all of the core developers are responsible for reviewing the Apache-CVS mailing list to ensure that the changes are appropriate.”
[3] has also mentioned Apache releases management as following:

“When the project nears a product release, one of the core developers volunteers to be the release manager, responsible for identifying the critical problem that prevent the release, determining when those problems have been repaired and the software has reached a stable point, and controlling access to the repository so that developers don’t inadvertently change things that should not be changed just prior to the release.”

[3] mentions that Mozilla Project maintains a roadmap document that specifies what will be included in future releases, as well as dates for which releases are scheduled. Mozilla applies Bugzilla problem-reporting mechanism for bug reporting and enhancement request process. Bugzilla allows bug reporters to see the most recent bugs to avoid bug report duplication. The development community can browse Bugzilla to identify bugs or enhancements they would like to work on. Fixes are often submitted as attachments to Bugzilla problem reports.

Both [2] and [3] are trying to find quantitative results for the following questions to understand how the Apache/Mozilla came to exist:

Q1: What was the process used to develop Apache/Mozilla?
Q2: How many people wrote code for new Apache functionality? How many people reported problems? How many people repaired defects?
Q3: Were these functions carried out by distinct groups of people? Did large numbers of people participate somewhat equally in these activities, or did a small number of people do most of the work?
Q4: Where did the code contributor work in the code? Was strict code ownership enforced on a file or module level?
Q5: What is the defect density of Apache code?
Q6: How long did it take to resolve problems? Were higher priority problems resolved faster than low priority problems? Has resolution interval decreased over time?

With the quantitative results, the Apache project and Mozilla project shares a number of hypotheses:

“Hypotheses 1: Open source development will have a core of developers who control the code base. This core will be no larger than 10-15 people, and will create approximately 80% or more of the new functionality.”
Hypothesis 2: For projects that are so large that 10-15 developers cannot write 80% of the code in a reasonable time frame, a strict code ownership policy will have to be adopted to separate the work of additional groups, creating, in effect, several related OSS projects.
Hypothesis 3: In successful open source developments, a group larger by an order of magnitude than the core will repair defects, and a yet larger group (by another order of magnitude) will report problems.
Hypothesis 4: Open source developments that have a strong core of developers but never achieve large numbers of contributors beyond that core will be able to create new functionality but will fail because of a lack of resources devoted to finding and repairing defects in the released code.
Hypothesis 5: Defect density in open source releases will generally be lower than commercial code that has only been feature-tested, i.e., received a comparable level of testing.
Hypothesis 6: In successful open source developments, the developers will also be users of the software.
Hypothesis 7: OSS developments exhibit very rapid responses to customer problems.

The above hypotheses are for both Apache project and Mozilla project except there are alternative hypothesis 1 and hypothesis 2 for Mozilla project as specified in [3]:

Hypothesis 1a: Open source developments will have a core of developers who control the code base, and will create approximately 80% or more of the new functionality. If this core group uses only informal, ad hoc means of coordinating their work, it will be no larger than 10-15 people.
Hypothesis 2a: If a project is so large that more than 10-15 people are required to complete 80% of the code in the desired time frame, then other mechanisms, rather than just informal, ad hoc arrangements, will be required in order to coordinate the work. These mechanisms may include one or more of the following: explicit development processes, individual or group code ownership, and required inspections.

Finally, it is feasible to perform “hybridized process of commercial and OSS practices”. Personally, I think the OSS process can be applied to the commercial software, but the restriction and closeness of commercial software team might reduce the effectiveness of OSS development.

REFERENCE
[1] The Cathedral and the Bazaar (Raymond)

[2] Mockus, A., Fielding, R. T., and Herbsleb, J. 2000. A case study of open source software development: the Apache server. In Proceedings of the 22nd international Conference on Software Engineering (Limerick, Ireland, June 04 - 11, 2000). ICSE '00. ACM, New York, NY, 263-272. http://doi.acm.org/10.1145/337180.337209

[3] Mockus, A., Fielding, R. T., and Herbsleb, J. D. 2002. Two case studies of open source software development: Apache and Mozilla. ACM Trans. Softw. Eng. Methodol. 11, 3 (Jul. 2002), 309-346. http://doi.acm.org/10.1145/567793.567795