@Kaz the idea of many eyes watching over the code has been close to the core of the open source movement for a long time (don't know if from the beginning). And yes, that does not prevent bugs. It only helps in catching them after the fact. On the other hand, if version 3 was good, version 5 is bad, and the original developers are busy with version 8... Somebody fork that poor software already. Take over the development from version 3, cherry-pick what you need, and continue forward.

@Kaz It is true that without requirement specifications the development can go awry. However, with requirement specifications it can also go awry. It will come down to the discipline of the developer and watchful eye of supervisors of the community at large to keep it line. Anyway, I'm not suggesting to develop software without requirements, but that often the initial effort - let's say proof of concept - does not have well documented requirements, at least not publicly. And that in FLOSS they often specify requirements using using issue trackers, tests and so on. Call it informal if you will.

@kuma Besides, I challenge the idea that you need requirements for a software. And suggest that requirements are for software projects. And that there are many software projects in the making of a software. Of those, only one was the inception, and that one is often the worse documented. You don't see fixing an issue as a project? How about change management? - The issues, in the issue tracker, those are requests for change, they bring new requirements (or remind of old ones in the case of regressions). To implement those changes, we do projects (with design, and testings, programming, etc).

@kuma I don't know much about Signal history, but if Wikipedia is to be believed, two people created the Whisper Systems company, which made privative products, and was acquired by twitter. One of the two co-founders merged technology from the products, got founding from one co-founder of WhatsApp, and called it Signal. We are not getting requirements documents of that one.

@kuma One or two people is very common. However, true, that is not always the case. Going over your examples… The odd one out is VLC. I found this: wiki.videolan.org/Documentation:History - Don't know how that worked. GIMP history is interesting, it was started by two people, and it is probably the closest to what you are looking for. See gimp.org/about/prehistory.html and gimp.org/about/ancient_history.html.

@joshp At least we have Computerphile: youtube.com/watch?v=PZRI1IfStY0

Mirror of Virtual Methods and Brittle Base Classes linked by Brian above. And Method Hiding Apologia linked by Jalayn.

Queue theory: space and time are decoupled. String theory: subatomic particles are actually serialized objects. 🙃

For once, you could delete your question yourself, and post a new one. However, just the same question would not only not work, but would not be well received to just re-post it. Trying to look at questions on the same vein, I find most are closed. Perhaps a chat room to talk about it? We are already making a long conversation here as it is. Edit: at least there are some open questions of the form "what paradigm to choose for XYZ" and "What's the benefit of this paradigm over this other". Made a room: chat.stackexchange.com/rooms/116551/…

Yes, some people don't want to listen to what they don't agree. Yet, I doubt they think they are not listening. I'm no fan of Java, but I don't think the example in article are representative of good use of it. Btw, I see is a vote to reopen. I'd probably vote that too if you narrow this. Disadvantages compared to what? For what? - Most would agree that doing everything OO is a bad idea. For instance, OOP is often procedural internally, as the StackOverflow quote suggest. OO always needs an agent/service. Does the garbage moves itself? You.Get(What: Garbage, From: Sink.Under); (Not Java).

Here: Functional Principles for Object-Oriented Development. You may also be interested in The Best Refactoring You’ve Never Heard Of (audio issues, but there is no better version). More fodder for you: Boundaries when it talks about paradigms (10 minutes, 18 seconds).

Of course, asking "what are the disadvantages of OOP? is going to get closed. OOP is a tool. Sometimes it is the right tool, some times it isn't. If we want to know if it is a good tool, we need a task you want to solve. Besides, it is sad that Java's brand of OO is considered the default. However, Java has some functional features now. It isn't OO vs Functional either. There are other approaches even if less popular. Data driven, and logic programming come to mind. I also want to recommend "Functional Principles for Object-Oriented Development" by Jessica Kerr, if you can find it to watch.