Hi Mike, On Mon, Aug 23, 2010 at 1:07 AM, Mike Witt <[email protected]> wrote: > For whatever it's worth I'd like to say that I emphatically agree > that more attention to fixing bugs (presumably at the expense of > adding features) would make Sage *much* more viable from my point > of view. My point of view being as: > > (1) Not a developer, but simply a user. > > (2) Not a mathematician, but someone who is (late in the day :-) > slowly making my way through the undergrad math/physics > sequence. > > (3) Someone who has tried unsuccessfully to get classmates and > instructors interested in Sage as an alternative to certain > other "M"s. > > (4) Someone who, not being particularly brilliant with this > stuff, probably represents more of what a "typical" user > would look like if Sage ever attained widespread use. > > Having said this, I can't help but wonder what possible > motivation there could be, among developers, to do something > like a bug fix release? It sounds like of boring ...
My response can be summarized in one word: accountability. As a first step in understanding accountability as it applies to computer software, let's look at the notion of accountability in civil engineering. When a bridge collapsed, it is possible to trace accountability back to the company/individual who designed that bridge or to the construction company that built that bridge. The design or construction company/individual can be sued for negligence and so on. But how does accountability come into play in software? First, a software license usually has an indemification clause(s). An open source license usually has the explicit statement to the effect that the software concerned is provided as is and without any warranty whatsoever. What other factors can be barriers to accountability within the realm of software? Helen Nissenbaum can provide us with some insights into this question in her two papers * Helen Nissenbaum. Computing and accountability. Communications of the ACM, 37(1):72--80, 1994. * Helen Nissenbaum. Accountability in a computerized society. Science and Engineering Ethics, 2(1):25--42, 1996. In both of these papers, Nissenbaum identifies four barriers to accountability with respect to computer software: (1) the problem of many hands, (2) software bugs, (3) computer as a scapegoat, and (4) ownership without liability. The problem of many hands can be understood when we consider a mishap with a piece of software. A complex software package is likely to be the result of many people. When the use of that software results in a mishap, on whom do we rest accountability? This issue is more concerned with closed source, proprietary software than it is with open source software. Individual accountability is built into the process of open source software development where one knows who wrote a patch that was accepted and integrated into the mainline source tree. An open source software contributor enjoys a greater degree of autonomy than is enjoyed by a closed source, proprietary counterpart. But it can be difficult for a bug to be fixed once its open source contributor has moved on or is unwilling to fix the bug. Next comes the issue of software bugs. If you accept that bugs are inevitable, this raises a problem with regard to accountability for such a mentality can encourage sloppiness in how a software package is developed. The open source community treats the eradication of bugs as a group effort, as a group responsibility. Think of the famous phrase attributed to Linus Torvalds: "Given enough eyeballs, all bugs are shallow." Once a bug is identified/reported, what can we do to get it fixed? How can we encourage people to be active contributors instead of users? Both groups of people are valuable to the success of an open source software project. But a small active contributor base is not likely to bring the number of open bugs down. Thirdly, the problem of the computer as a scapegoat is a general problem and it is not specific to open or closed source software. I'll leave this problem as it is and won't discuss it any more in the context of open source software. Finally, the issue of ownership without liability is not relevant to open source software. Any open source license must pass the test of the Open Source Definition [1], which characterizes open source software as something that is not owned by any one individual or company. Open source software according to my reading of the Open Source Definition is more properly a commons in the sense that the open air is a commons for anyone to enjoy, or that a public park is a commons for the use and enjoyment of the people of a community. There is no notion of anyone or any company owning an open source software package in the same way that no one owns the air or the public park. But without ownership, how does accountability comes into play in open source software? I think that comes down to one's sense of ethics as an open source contributor. How can a person be a responsible open source contributor? [1] http://www.opensource.org/docs/osd -- Regards Minh Van Nguyen -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
