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: 5, Insightful) by Thexalon on Sunday March 29 2020, @12:14AM (1 child)
The seven real stages of any kind of coding, OSS or not, are:
1. Shock: The utter surprise that there isn't a tool to do this already, or surprise that all the existing tools to do this suck.
2. Denial: A complete failure to recognize that you're either trying to solve a stupid problem, or are trying to solve it in a stupid way.
3. Anger: Why doesn't this code F**KING JUST WORK!!!
4. Bargaining: Believing that if you can fudge the heuristics just right, this might actually work.
5. Depression: This doesn't work. It's just yet another sucky tool that does nothing useful.
6. Testing: Well, if we carefully ignore all the problems in our acceptance testing, maybe QA won't notice the problems.
7. Acceptance: The tool gets adopted, even though it doesn't work properly, because the suits were taken in by the shiny graphics and marketing drivel.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(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.