1. Reading Material Designing Survey Questions http://www.tgsa.edu/online/cybrary/lwedekin.html Extracting Useful Information from Survey Data http://www.cmis.csiro.au/statline/1999/feb99.htm 2. Existing Surveys Data existing in inadequate; doesn't focus on S.E. issues. Previous surveys include: - http://www.osdn.com/bcg/ * population survey of hackers from sf.net * motivation * dedication - http://floss1.infonomics.nl/ * population survey * personal questions * motivation * dedication * involvement with projects * opinion * preferences * expectancies - http://orbiten.org/ofss/01.html * automated survey, looks at project code * diversity and concentration of contributors * intersection between projects * sharing of code * multiple developer participation * changes to codebase/developerbase - http://seven.bf.rmit.edu.au/~haggen/Delphi/ - Multiple informal surveys carried out on websites, most focus on personal aspects of developers or the population as a whole. None focusing on software engineering as I see. Survey focuses on a selected group: leaders of free software projects. Partly factual, partly opinion-based. (is this good or not?) 3. Methodology 3.1 Primary Objectives - Highlight differences between conventional process and OSS (through hypothesis) - Generate information about process activities in OSS (through hypothesis and data gathered on process) 3.2 Initial assumptions - Many projects have tools available but don't use them (sf.net, etc) - 3.3 Hypothesis, relevance in [ ] [ ] Requirements are usually obtained through standards or imitating pre-existing software (usually proprietary). [ ] Formal methods are usually not used in OSS projects. [ ] Projects that start out in company/organizations use more process and tools. [ ] Projects that are based on a code fork use more process and tools. [ ] Larger projects use more process and tools. [ ] Many people involved in the project will work in more than one area in the project -- design, code, docs, release, qa, etc. [ ] Development language presents an important entry barrier to the project(1). [ ] Development speed changes over release. (1) We might go as far as saying there are subprocesses inside the project separated by language, in some cases. Documentation is a separate process, of course. 3.4 Approach - Measurement of process activities should be done through verification of its subproducts: test suite or plan for testing, etc. Otherwise the questions are too vague: "Was testing performed?", etc. 3.5 Interesting targets - Non-code contributors - Unability to assess the # of users - Need for good verbal communication skills 3.X Unanswered questions - Determine if larger projects use more tools (they do) - Does release time change the life of the project a lot? IOW, does the project release cause a discontinuity in the data from before and after release? Is this only pushed on by time? - Do projects based on standards develop more easily in the S.E. sense (do they?) - Does the initial motivation for creating the project influence S.E. (XXX: fix this question then!) - Do code forks have different S.E. profiles (i think yes, because a lot of experience comes with it, but it may have to do with a size factor only) - Does the number of developers change a lot after release? Is this related to any of the other aspects? - Does the fact that experienced developers are involved influence the use of tools and process or not? - Are non-public releases commonly done before release? - Do projects with a lot of process activities take longer or sooner to attain a public release? (longer, i think) - Do projects with process make for stabler first releases (sure) - Do projects with process make for more featureful first releases (is there a connection?) - What are the main ways a first release is publicized? XXX: 7 questions on process activities - Specs - Design - UI - Testing - Documentation - Review - Tools - Missing topics from survey: - Internationalization, and special treatment for localizers and their tasks in team size. - Clarify and perhaps an extra question about distributed development. - A better way to determine how contributors participate ("Most contributors will usually send in a single patch or change and never contribute again", Localizations, etc. etc.) - A UI assertion "The user interface is well established for this kind of application". - Make WWW and CVS tool options better - does it mean there is no website, or that the website isnt used as a communication tool for the project; and does not including CVS mean that it isn't public or that it isn't used at all? Maybe make a radiobutton thing: Not installed Installed but Installed, used Installed, used not used but not public and public ( ) (*) ( ) ( ) - Have an option for the Team geographical constraints that says "Some people in the team have met but do not work regularly together". - Single-person project contrasts too strongly with team aspects - Do you have a stable/development fork? - Started the project because there was no other OSS/FS alternative and I wanted to contribute one. Cool future item: see time of past 5-10 releases and make average and see how the project tactics work out wrt the release strategy. - Bad questions - Website tool - Geographical constraints - Some sort of end-user docs XFREE86 ansic: 1913424 (94.01%) cpp: 37081 (1.82%) sh: 34486 (1.69%) asm: 14700 (0.72%) pascal: 13773 (0.68%) tcl: 9182 (0.45%) yacc: 3397 (0.17%) python: 2383 (0.12%) perl: 2292 (0.11%) objc: 1710 (0.08%) lex: 1643 (0.08%) awk: 933 (0.05%) lisp: 304 (0.01%) csh: 58 (0.00%) sed: 57 (0.00%) - Categorization I've followed the rule of trying to group things into the largest groups that are not too vague to be meaningless. - Editors: I've picked Elvis and VI as text editors (as I would have Emacs) and so it goes in with browsers and etc. If they were *specifically* for code development (as IDEs are) they would go into software development. - Thumbnail/image gallery gnerators are in Browsers for ms, since they are less an imaging application, and more an image browser. - Databases are obviously associated with software development, so it is a bit mor restrictive - what fits in Databases should not go in Development. There arent any other subdivisions of Software Devel though. - Wiki and others are covered as browsers and office applications. All CSCW apps will probably come in here.