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/
No comments:
Post a Comment