Open Source Software Process ============================ What is a software development process? --------------------------------------- Wikipedia defines a software development process as "a structure imposed on the development of a software product" You can view a process as a set of rules or guidelines that tell you: * what practices to follow in developing software, and how to follow them * the order and timing of applying those practices * the roles of different people in the software team, and how they coordinate Why do we have process? ----------------------- (1) to improve quality e.g. avoid bugs and vulnerabilities, ensure good peformance, ... (2) to improve productivity e.g. to write software more quickly (3) to make software creation more predictable e.g. avoid software that is late or over budget. Even if we can't deliver software as quickly as we'd like, it's better to know that in advance, than to make promises we can't keep. Why does process matter to you? ------------------------------- In short, you are each part of teams delivering software. You are expected to produce that software at a high level of quality. We want you to be productive so you can make a significant contribution to the project and still have time for your other classes. And, it's best if you can This means you need to follow a software process. Futhermore, since process is partly about coordination, and processes usually only work when they are consistently followed by all team members, you need to learn and follow the specific process from your open source team. What makes up a software process? --------------------------------- Planning: Breaking up the construction project into tasks, deciding in what order you will do those tasks, and estimating how long each task will take. Dividing up the work among teams and team members. Requirements: Deciding what product to design. Writing down the requirements for the product, both in terms of what it will do (functional requirements) and with what quality it will be done (quality attributes, such as security, performance, reliability, etc.). Changing the requirements based on feedback from clients or lessons learned during implementation. Project management: Tracking progress against the plan. Adjusting the software plan to deal with changes to the requirements and the events that come up. Analyzing how well the software process is accomplishing its goals and changing it. Design and implementation: Breaking the software system into components, and designing the component interfaces. Writing code, generally following coding guidelines. Checking code into a repository--often only after certain quality assurance steps have been taken (below). Quality assurance: Inspecting and testing code to make sure it meets the requirements (functional and quality attributes). Tracking bugs as they are identified, merging duplicate bugs, reproducing reported bugs, assigning them to developers, adding test cases that demonstrate the bug, and marking the bug fixed when a fix is checked in. Perhaps running static analysis tools or automated tests on code. Why do different teams have different processes? ------------------------------------------------ The simple answer: because each project is different. Constraints related to the domain of software, the programming language and tools used, the developers experience, etc. drives projects to use different processes. Can you think of an example? Why do OSS developers donate their time? [SFF+06] ---------------------------------------- * To learn and to share what they know (about software, design, methods, tools, practices) [does this sound familiar?] - Free and Open Source Software (FOSS) developers often have higher average wages and better employment opportunities [Hann et al. 2002, Lerner and Tirole 2002] * Personal enjoyment - they have chosen their role in the project * Recognition by peers What makes open source processes different? ------------------------------------------- The Cathedral and the Bazaar [Raymond] * Closed-source development: like the building of a cathedral; central planning, tight organization and one process from start to finish. [Wikipedia] * Open-source development: like "a great babbling bazaar of differing agendas and approaches out of which a coherent and stable system could seemingly emerge only by a succession of miracles." [Raymond] Differences [Bar & Fogel, as cited in Wikipedia]: often users write the bug reports and feature requests. Decisions about which bugs to fix and features to make are done in a more distributed way; people who know about or care about a bug or feature may fix/implement it themselves. "Generally there is no formal project management regime, budget, or schedule." [SFF+06] because the project is not centrally organized, and because developers are volunteering their time. Project communication systems that are asynchronous, persistent, searchable, traceable, public, and globally accessible [Yamauchiet al. 2000] Some Advantages of Open Source Projects --------------------------------------- Scalability of labor [YMP+06]: Brooks's Law [Brooks75] states "adding developers to a late project makes it later." But in FOSS projects, debugging/QA scals with the number of developers, because they do not require as much communication. It is claimed that "given enough eyeballs, all bugs are shallow" [Raymond] (often called Linus's Law, after Linus Torvalds). This is not strictly true (there are diminishing returns to inspection, and there is no empirical evidence that OSS software is more reliable than closed-source software) but nevertheless, having many people using your product and allowing them to expend energy finding the bug themselves does result in finding a lot of bugs without paying testers. Core/periphery structure [YMP+06]: "A relatively small number of core developers are responsible for ensuring the architectural integrity of the project, e.g. the vet user contributions and bug fixes, add new features and capabilities, and track day-to-day progress on project goals and tasks. In contrast, the periphery consists of the hundreds or thousands of user community members who help test and debug the software released periodically by the core team." Short feedback loops [YMP+06]: If a bug is discovered in the periphery, it can be quickly reported, fixed, and incorporated as a patch. This works in part because the discoverer (who likely cares about the bug) can work independently, with access to the current source and test cases and an easy but asynchronous way to provide the developers with a patch. Leverage of the user community [YMP+06]: If users find bugs in a closed-source system, there's not much they can do. But if they find a bug in an open source system, they are incentivized to help with the fix, because then the fix will come quicker (as opposed to coming on the closed-source company's schedule). Furthermore, they can help more, because the code is available. Some Limitations of Open Source ------------------------------- Can't work something out together on a whiteboard. Can't walk to your teammate's cubical - he or she may not even be online when you are working When does this cause a problem? * figuring out broad vision and strategy * high-level product design These activities are best done in face-to-face meetings. There is evidence for this in the software engineering research literature, and it is also folk wisdom in organizations such as GitHub. Mitigation strategies * meet in person every now and then - especially at the beginning of a project * follow rules such as those of GitHub.com (see other sheet) Tool-based mitigations * email lists (archived) * IRC, web forums (with transcripts) * wikis * distributed version control systems (Git, Mercurial) * Bug trackers (Bugzilla, etc.) * Continuous integration (e.g. Tinderbox) Runs builds on every checkin, executes tests, identifies failures and the corresponding breaking check-in Questions for you to consider in your OSS project process report ---------------------------------------------------------------- How is planning done? Are there milestones or releases planned for the future? Is planning any different in working with your mentor than other people (not in any class) working on the project? What forms of communication are used in your project? Describe any email lists, wikis, etc. in frequent use. Can you tell whether you communication with your mentor differs from typical interactions in your project? Are there coding guidelines followed by your project? Provide a reference or link to them. What process must be followed to check code into a repository? How is quality assurance done? Are code inspections/reviewed used in your project? How and when? Are there checklists for code inspection? How is testing done--are there standards you are supposed to follow in writing tests? Are there tools or libraries used for testing and inspection? Does the QA process include running any static analysis tools? What is the lifecycle of a bug? What stages does it go through in the bug tracking system? Is it any different for features? NOTE: Answer as many of these as you can on your own. If you simply ask your mentor all of these questions you *will* annoy them, and I do not want to hear them complaining to me about this assignment. Instead, it is your responsibility to be proactive, and look at project documentation and tools to find out how the project works. It is OK if you get more details on some parts of the process than others; just talk about what you can find. If you do ask your mentor questions about process, make sure they are (A) relevant to your own work on the project, and (B) information that it is hard for you to get yourself. Sources: [Raymond] Raymond E., The Cathedral and the Bazaar: Musings on Linux and Open-source by an Accidental Revolutionary, O’Reilly, 2001. [SFF+06] Walt Scacchi, Joseph Feller, Brian Fitzgerald, Scott Hissam, and Karim Lakhani. Understanding Free/Open Source Software Development Processes. Softw. Process Improve. Pract. 11:95–105, 2006. http://www.ics.uci.edu/~wscacchi/Papers/New/SPIP-FOSS-Intro-Dec2005.pdf Ryan Tomayko's blog http://www.cs.umd.edu/~aporter/Docs/SPIP-OSS.pdf http://en.wikipedia.org/wiki/Software_development_process http://en.wikipedia.org/wiki/Open-source_software_development http://tomayko.com/writings/adopt-an-open-source-process-constraints?utm_medium=referral&utm_source=pulsenews