-*- mode: outline; coding: utf-8; fill-column: 80 -*-

* Ideal software development model.

This file mainly discuss about open source software project.

* Open source.

Open source software project have freedom how develop project and which
development toolchains use.

* Close source.

Close source projects have proprietary nature because of:

 * interest to make money (another parties can not easily reproduce project or
   steal realisation ideas/code, allowing another party get same product and get
   company money)
 * low code quality (to stop stain company good name or to stop malicious
   attacks based on code analysis)
 * security consideration (to hide protocols and data format to make harder
   malicious attack)
 * business model (closed data formats allow vendor lock)

Disadvantage of closed source project (in many case):

 * you can not directly contact with developers (only through support)
 * low support quality
 * paid support (and you have no enough money)
 * can not access to product bug tracing system (you only can submit bug via
   crash report application or technical support, publicly appear internal bug
   tracing can damage product reputation

* Component of software project.

 * Src (sources).
 * Doc (documentation).
 * VCS (version control system).
 * BTS (bug tracking).
 * News (project news/history/changelog).

* Project sources.

** README file.

Assumed that users first read this file before start using project.

 * Project name.
 * Project goal.
 * Point to license statements.
 * Point to build instructions.
 * Point to documentations.

** INSTALL file.

 * List of supported platform.
 * Build dependencies/prerequisites.
 * Build instructions.

** COPYING/LICENSE file.

COPYING usually used for GNU GPL like license. Another license put in LICENSE
file.

If some component comes with different license put it into file with name like:

  LICENSE.libmy LICENSE.regex LICENSE.doc

** AUTHORS file.

Usually regular contributors.

 * List of project members with contact info (email/phone/home page/address/etc).

** THANKS/CREDITS file.

Usually casual/non-regular contributors.

 * List of contributors with contact info (email/phone/home page/address/etc).

** NEWS/CHANGES file.

Here goes news and descriptions of user visible changes:

 * Important project news.
 * New features.
 * Obsolescense/deprecation of UIs/APIs/protocols/formats.
 * Incompatibilities with previous version.

** HISORY file.

 * Project history in long perspective.

** FAQ file.

 * List of frequency asked questions with answers.

* Docs.

* Project home page.

Project home page must provide:

 * project name
 * short info about project goal
 * project license
 * current project status
 * links to binary release
 * links to source release, how to get latest source from VCS
 * links to online/printed docs
 * how report bug (BUGS)
 * where send patch
 * contact info

Additionally:

 * help welcome, requirement to join to project
 * mail/news list for users/developers, how to subscribe/unsubscribe, where
   find archive, how search for keyword in archive
 * project history (NEWS, ChangeLog)
 * project policy (HACKING)
 * how build project (README, INSTALL)
 * list of contributor with contact info (MAINTAINERS, AUTHORS)
 * who use project

* VCS.

TAGS: VCS, version control system, SCM, source code management, DVCS,
      distributed version control system.

 * CVS
 * SVN
 * Mercurial (hg)
 * git
 * bazaar