This post lays out the different stages of openness in Open Source Software (OSS) and the benefits and costs of each.
[...] Is Linux as open as TensorFlow? How about my personal project? Is that the same? [ . . . . ]
To help give depth to this topic, this post structures opening software into a sequence of stages of openness.
- Publicly visible source code: We uploaded our code to GitHub
- Licensed for reuse: And let people use it for free
- Accepting contributions: And if they submit a patch, we'll take the time to look at it, and work with them to merge it in
- Open development: And when we work we'll make sure that all of our communication happens in the open as well, so that others can see what we're doing and why
- Open decision making: And that communication will be open to the public, so that everyone can weigh in, vote, and determine what happens to the project
- Multi-institution engagement: So much so that no single institution or individual has control over the project
- Retirement: So now we can retire, and know that the software will live on forever
To be clear, I'm not advocating that going deeper into this hierarchy is a good thing. Often it's more productive to stop somewhere around 3 to 5 [ . . . ]
What about code written merely to solve one person's problem or to amuse themself?
(Score: 0) by Anonymous Coward on Sunday March 29 2020, @05:47PM
> 4. Bargaining: Believing that if you can fudge the heuristics just right, this might actually work.
Ha ha - very true! This is where many resources get spent in R&D. Nobody wants to call it like it is.