Open source development model and methodologies. 1 Computer

Open source development model and methodologies. 1 Computer science department third year cs Lecturer : yasmin maki

There has always been methodology since when there has been a need to create solutions to problems. In the case of open source software development, methodology has been essential even though not very visible in creating successful development processes. The Linux and Apache projects are but a few of success stories of open source development projects. 2

The difference between open source projects, development processes and proprietary methods Complex OSSs are built by a large number of developers around the world with a common norm of openness; some of these developers are volunteers while others are supported by companies around the world. 3

The difference between open source projects, development processes and proprietary methods The workload usually is not assigned to the developers instead the developers choose to undertake whatever work they choose to perform There are usually no detailed requirements, design, project plan nor schedule 4

Software Development Methodologies :The most common methodologies are chosen and they are The waterfall model The Rational Unified Process Model (RUP) The Agile Model o Scrum Open Source Development mode 5

Open Source Development Model The model is said to be a fluid development process characterized by : increased intrateam collaboration, continuous integration and testing and greater end-user involvement; this model describes a process and characteristics that would apply to most open source projects but also states that every open source project could have its own development process. 6

The model runs under the Feature Development life-cycle and this process consists of: 1. Feature request process. 2. Architecture and Design Discussion. 3. Collaboration on Implementation. 4. Source code submission. 5. Continuous testing and Integration. 6. Source code release 7

Feature request process: When there is a need for a new feature, a feature request is create to ensure a common understanding within the development team : of what feature has been requested, its priority, development status, associated bugs, blockers and scheduled release. The project team contributors evaluate the request in terms of its need, strength and if it is fit for a future release. This feature request must be communicated and transparent to all team members whether new or old member. 8

.Architecture and Design Discussion The importance of communication comes under the architecture and design discussion phase and the most commonly used form of communication is : mailing list, Internet relay chat (IRC) client for design meetings and user support meetings taking into consideration that English might not be the primary spoken language of all participant 9

.Collaboration on Implementation After a sustainable communication channel has been created, then a collaborative development phase can ensue. Putting in mind that these team members can be from around the world, a project tool that support effectively code contribution must be involved for example the open source git repository. 10

.Source code submission The process begins with collaborative development among the team’s subset of developers who have taken the responsibility for developing the feature. When the code is functional, it is submitted to the project advocator over the mailing list that then together with other project participant may give feedback on the feature and decide if it can be accepted into the source code of the main software. The smaller the patch that is submitted at an iteration the easier it is to finding bugs and fixes unintended consequences in the source code . 11

Continuous testing and Integration Most open source project have automated build suite and test suites that evaluate new code immediately after integrations to identify functional issues during active development, which is why small incremental are favorable to ensure that quality of the source code is assured on all levels. 12

Source code release For all the feature codes to be well integrated, a release management is put in place as a development tree to make retrieving the most current stable release available to all users to continue work on 13

Core characteristics of open source development model are: that code contributors are responsible for development and maintenance of code that is; one or more of the project advocators checks and integrates source codes written by contributors into the body of existing codes 14

Another life cycle model for the development of the OSS The United States Department of Defense (DOD) proposed a life cycle model .The main focus of this development life cycle is on the contributor roles who participate in the development process of the OSS. The OSS development model presented by is shown in Figure below. 15

:The OSS development life cycle consist of following Developer: Developers consist of the persons who imitated and contributed .majorly in the development of the OSS The developer is responsible for the actual working of the OSS in right and .proper manner 16

Trusted Developer: Trusted developers consist of the persons who contribute in the development of the OSS continuously and they gained the trust of the initiators through their continuous involvement in the development process and became the part of the core developer community. Trusted developers are allowed to make updating and changes in the trusted repository directly. The entire user, distributor sends their request for change and updation to the trusted developer. 17

Trusted Repository: Repository means the data house. The repository in OSS development specifies the house from where all the information related to the OSS can be retrieved. The user and trusted developers can access the repository directly or through the distributor. The trusted repository specify the space from where user or trusted developer can get the official version of the software and get other related information such as bugs report, change log, documentation etc. 18

Distributor: Distributor is the persons who have the copy of developed OSS and they are using it and perform other task such as modify, integrate, testing, configuration etc. 19

.User: User is the normal person who uses the OSS .User can be categorized as Passive and Active user The Passive users are those who download the software for use, study they never participate in development. The Active user participate in the development process by performing task as finding bug, giving review about the OSS etc. 20

In this development process the flow of the source code is shown as ,.developer - trusted developer - trusted repository - distributor - user i.e it follows the top-down approach, where as feedback/bug report use .bottom-up approach It flows from user - distributor - trusted repository- trusted developer .developer 21