-
Notifications
You must be signed in to change notification settings - Fork 19
Lit Review
The license under which copyrighted code is released is possibly one of the most powerful non-verbal cues a hacker can send to the development community. It is a statement of exactly what the original author permits others to do with their own original work, and any future conditions under which that work should be released. (Page 8)
A useful characterization of the FOSS ecosystem is that of a river. Code bases that a project depends on are upstream from that project; changes made upstream flow down the river and impact anyone else relying on their code. Users, developers, or other dependents of a code base are downstream; changes made flow down the river to the consumers of that code. (Page 12)
The incentive to prove your worth shifts to the side of the developer. As is true of many technical and artistic disciplines, the quality of a programmer's mind and work is not easy for others to judge in standardized metrics. To know what is really good code and thus to assess the talent of a particular programmer takes a reasonable investment of time. The best programmers, then, have a clear incentive to reduce the energy that it takes for others to see and understand just how good they are. Hence comes the importance of signaling. The programmer participates in an open source project as a demonstrative act to show the quality of her work. Reputation within a well-informed and self-critical community becomes the most efficient proxy measure for that quality.
Consider now the case of open source software. An individual developer can, if she chooses, keep her software code private, and charge for that product. In that case the private gains would accumulate (in some proportion) to the developer and purchaser (the end users). There are not necessarily any positive externalities in this transaction.
Suppose the code were, instead, open source. The benefits from that piece of software would then accumulate to (a greater number of) end users AND it would also benefit other developers. Users would also have a potential of even greater gain with open source, since they would have the ability to refine or enhance the product themselves.
Importantly, other developers benefit from the open-source code by
- learning from the code,
- incorporating their product or components into their work, and/or
- by expanding/modifying the original code.
Open source development can thus be thought of as disseminating knowledge and ideas in addition to providing a specific product to market. And as before, these benefits accumulate to those who are not part of the initial transaction.
- Developer guide
- How to get the source code
- How the code is laid out
- How to set up the build system
- How to run a build
- How to contribute
- Dev Responsibilities
- The public repo is the source of truth. Once you’ve published your source code to a public repository (or repo), all development should happen in that repository. The public repo shouldn’t simply be a clone of an internal one. If the project is being actively developed, then that development should happen exclusively in the public repo in order to be as transparent as possible. Developing in private and then updating periodically prevents the use of pull requests and makes forking your project extremely difficult and frustrating.
- Plan in public. Use a public bug tracker to track all issues, so that others can see what’s being worked on and what’s already been reported. Post a road map somewhere public that shows plans for development. Be as transparent about the development process as possible. In short, open-source the way your project will grow and evolve.
- Dedicate company time. If you are the primary author of the project and you’ve open-sourced the code, then you (or a delegate) should set aside time to interact with external contributors. That means making timely responses to pull requests and issues, which in turn means setting aside time daily or weekly. This has now become part of your full-time job, not just a hobby.
- Open channels of communication. Give external contributors a way to interact directly with the maintainers. This could be through a forum, mailing list, IRC chat or another channel. Make sure that these systems are public; for example, an IRC chat should not be on your company’s chat server. Plenty of free communication services exist to make use of. The simplest and least disruptive method is to create a free mailing list using Google Groups or Yahoo Groups.
- Commit to document. Lack of documentation is a huge problem with open-source projects. From the start, commit to writing good documentation that explains not only how to use the project but also how to set up a development environment, run tests and work effectively with the code as a contributor. There is no better way to discourage people from using your software than to give them no way to get up and running on their own.
- Maintain regular outgoing communication. There should be a steady stream of outgoing communication about the project. At a minimum, post announcements about new releases and security issues that require immediate upgrading. Maintain changelogs that describe differences between versions, and follow a predictable and regular scheme in your versioning (such as by following semantic versioning). This will help both users and contributors understand the impact of filing issues and submitting pull requests.
- MIT:
The MIT License is a permissive license that is short and to the point. It lets people do anything they want with your code as long as they provide attribution back to you and don't hold you liable.
jQuery and Rails use the MIT License.
- Apache:
The Apache License is a permissive license similar to the MIT License, but also provides an express grant of patent rights from contributors to users.
Apache, SVN, and NuGet use the Apache License.
- GPL:
The GPL (V2 or V3) is a copyleft license that requires anyone who distributes your code or a derivative work to make the source available under the same terms. V3 is similar to V2, but further restricts use in hardware that forbids software alterations.
Linux, Git, and WordPress use the GPL.
- Licensing Requirements
As an independent developer you are under no obligation to use any license at all, but that may have unintended consequences. That's because many people believe that by providing no licensing terms they are releasing it into the public domain. In fact, the reverse turns out to be the case: If you release your code without any license then it is automatically copyrighted. That means that no-one can reproduce, distribute, or create derivative works from it.
- Permissive Licenses
But there is a potential drawback to using a permissive license, says Johnson. Other developers may be unwilling to contribute their own code to your open source project if it is licensed in this way, either for ideological reasons or because they may be unwilling to help any commercial project without being recompensed themselves, he says.