Done! Please let me know if any changes need to be made. Maybe a little to long?
@torjunkie Since most if not all of my wiki contribs require edits. Would it make more sense for you to make edits in place i.e just make edits to my post? I don’t mind and this would cut down on (sometimes large) semi-duplicate posts. Plus the edit history is still available.
BTW thanks for helping out with my edit backlog 
Libre Software Development VS. Development in a Company
The method used to development of Libre/free software can vary greatly between projects and factors such as software type and design goals of the project play an important roll when deciding which methodology to use. When developing proprietary software a more tradition method is typically used which used a centralized approach. In this model all aspects of the project are tightly managed and participants are given clearly defined rolls with in the project. Only a select few developers have access to the source code and its not uncommon to have many participants dedicated to core development, project management, implementation and bug tracking.
In stark contrast is the Libre[1] model which uses a decentralized style encouraging the users themselves to become involved in the development of the project. In this model participants are loosely managed and the source code is publicly available. This model solves many of the issues faced with closed-source development by integrating users into the developmental process. Since Libre users have the freedom to use and improve the software any way they like[ref]Free software - Wikipedia, they make ideal candidates to also assume the role of a “developer” of the project.
[blockquote]The terms user and developer here refer to someone’s relationship to the open source software project in question, not to her identity in the world at large.
For example, if the open source project is a Javascript library intended for use in web development, and someone is using the library as part of her work building web sites, then she is a “user” of the library (even though professionally her title might be “software developer”). But if she starts contributing bugfixes and enhancements back upstream[2] – that is, back into the project – then, to the extent that she becomes involved in the project’s maintenance, she is also a “developer” of the project[ref]https://producingoss.com/en/getting-started.html[ref] [end/blockquote].
The relationship between users and developers can be very porous: every user is a potential developer. This principle is apparent in the Libre developmental model.
-
Users should be treated as co-developers - Users are treated like co-developers. As such they should have access to the source code of the software. Furthermore, users are encouraged to contribute additional code , bug reports, bug patches etc. By having more co-developers, the rate in which bugs are found and fixed increases substantially. Note that some users have advanced programming skills, and furthermore, each user’s machine provides an additional testing environment. This new testing environment offers that ability to find and fix a new bug. This in turn allows the software to evolve at a quicker rate. This concept is termed as Linus’ Law[3] which states:
[blockquote]“Given enough eyeballs all bugs are shallow.”[/blockquote]
-
Early releases - Since many volunteers are attracted to help develop the software based on the early release. This first version should be released as early as possible. This increases the chances of finding co-developers.
At least two versions of software should be available
-
- Stable version - This version has fewer features than the developmental version but has been thoroughly tested and most identified bugs have been fixed.
-
- Developmental version - For users that desire the use of the latest features not found in the stable version. Since this version has not been thoroughly tested, users must being willing to accept the risk of using a version that does not yet have all bugs patched. users can act as co-developers, providing bug reports and submitting bug patches for the developmental version.
-
Use a highly modular structure - The structure of the software should be modular allowing for parallel development on independent interchangeable components.
-
Frequent code integration - Code changes should be merged into a shared code base as often as possible to avoid the overhead of fixing a large number of bugs at the end of the project life cycle. Some open source projects have nightly builds[4] where integration is done automatically on a daily basis.
-
Dynamic decisions making structure - There is a need for a decision making structure, whether formal or informal, that makes strategic decisions depending on changing user requirements and other factors.
Development in a Company
Developing Libre/free software can not not be accomplished using a more traditional method. With a decentralize approach participants have much more flexibility in the developmental process which allows the software to be developed according to technical guidelines. Although this allows for companies to adapt according to different developmental needs. There are elements that can influence the overall outcome of software.
Third Party Software
For companies that only use software that is developed from within there company, the design goals which users expect can be met with less difficulty. However, this may not be the case for companies that also use software developed by other Libre/free companies. This software is developed according to the design goals of the third party project which may run counter to that of the company that uses the software. This applies not only to packages integrated into the software but also to the standalone software that may be used to support development. Changes to third party software can be time consuming and costly and smaller companies may not not have the necessary resources.
This simple illustration shows third party software used by Whonix. Note that some of the third party software also uses packages from other 3rd party project. Many of these companies do not share the same design goals as Whonix (advanced security and anonymity).
Firefox Web Browser --- Tor Browser --- --- Phabricator (bug/issue tracker)
\ /
Whonix ---> Infrastructure --- MediaWiki
/ \
Debian OS --- --- Discource (forum software)
/ \
Many software packages --- --- Google search engine
Company Size
The size of the company has a significant impact on development. Although Libre companies use the same methodology in development, the developmental practices used to achieve these goals is difference across companies of different sizes.
Large Companies
Many large companies employ many full-time employees and may receive contributions from hundreds[ref]The Linux kernel has about 200-250 companies on average per release contributing patches[/ref] of companies which use and depend upon the software, as well as hobbyist and research developers. Many of these companies also integrate third party packages into their software. If design changes are needed in this software the resources are available to either assign an employee to develop, test and submit a patch, or if necessary sponsor the third party company to make the desired changes.
Small Companies
Since small companies have limited resources they do not have full-time employees akin to larger companies (if they have them at all). Its not uncommon for these companies to have a 1 or possibly 2 core developers along with a small number of community members that make contributions towards development. Quite often, due to limited resources these companies must remain focused on core development which leaves less time to develop new features. This in turn prevents developers from presenting users with a unified experience[11] when using their software.
Making Changes to a Third Party Software
Its common for companies to use third party packages in their infrastructure and also integrated into their software. Although they may provide many benefits to the company, they are not always developed with identical design goals. This can lead to software not functioning as a user expects or may even break other packages. There are several options if changes are wanted in the third party software all of which require time and/or resources
-
Polity ask the company to make the changes
-
Submit a Patch that makes sense from their point of view
-
Fork the software and add your own patches
-
Use software from an alternate third party project
The methods used to change software is identical whether the request is from a large company or collaborator from a small community. When requesting changes try look at the software from the perspective of the third party project. The developers are more likely to accept the changes if they also benefit the design goals of the project. If significant workload is added with little benefit to the project, the changes would likely be rejected. Many project have instructions specifying how to submit patches on their web site. Whonix Patches Welcome[12]
The last option is to fork the software and add your own patch. Since maintaining an additional software package could increase the workload substantially. Forking software is usually not an option for small companies with little resources. The better option would be to submit a patch so all users of the software would benefit, not just users of software from one company.
Links
[1] Free software - Wikipedia
[2] Upstream (software development) - Wikipedia
[3] https://en.wikipedia.org/wiki/Linus's_Law
[4] Daily build - Wikipedia
[5] Mailing list - Wikipedia
[6] Internet forum - Wikipedia
[7] Git - Wikipedia
[8] Mercurial - Wikipedia
[9] https://www.discourse.org/
[10] User experience - Wikipedia
)