Article: Code Flows and Social Networks

- Exclude simple redistribution. New Code/Patch Flows.
- Examples:
  * Debian Packages usually include modifications, let it be in its own
  build system (include debian/ as a patch?)
  * VCS commits/updates/pushes/pulls/merges.
  * Patches through mailing lists, BTSs, PTSs, scattered in the web.
  * releases, pre-releases, candidates, betas.
- Flow direction: code goes from author to "user". Creates a Directed
  Graph.
- Is it a tree with a identifiable root? It's centralized/hierarchical.
  The CVS model.

		o CVS repo
	/	|		\
o committer	o committer	o user? sink?

- Remove sinks? Code only flows to them, not from them. Don't remove
  them. It shows (undesirable) cases where people create code but it
  only goes "downstream" (only one direction). Hypothetical example:

				o Upstream Project
/	/	/		|	{	\
|	|	o Contributor	o Debian	o Ubuntu
|	o Fedora				|
|	/					o Unlucky Person }
o Translator

Code goes in and comes out from Ubuntu, but it does not reach the
community.

- Sources only?? Original authors? Is there original works? Do people
  just leave the project without ever receiving a patch? Do we consider
  these OSS?

- Push/pull: request direction. Sending an email with the patch is push.
  A HTTP GET is pull. An email with HTTP URI is still push. CVS commit
  is push. CVS update is pull. Use original request. Push has same
  direction as code.

- Truly centralized systems never do the request. When using CVS, a
  contributor starts the request when commiting (push) and updating
  (pull). The repository/root/central point does not start them.
  Requests have only one flow to a sink.

- The distributed model: social network with some nodes with high
  connectivity and low degree of separation. Clusterization.

- git: analyse author, committer, tree maintainer, merges.