4 ms·

The FOSS development model is best suited for modular software where you have a relatively stable core and dozens of independent plugins for different purposes

The FOSS development model is best suited for modular software where you have a relatively stable core and dozens of independent plugins for different purposes by different authors, all implementing a well-defined interface. Any new contributor adds stuff in parallel, without being blocked. Other kinds of software which are a particularly good fit are non-end-user-facing middleware and libraries implementing a standard or a protocol. That standard or protocol pretty much describes what the software must do, and FOSS software often becomes the "reference implementation". Think of zlib, libpng, ffmpeg. For the regular monoliths you need a team that is much more well-knit and communication and focus is key. Each unit of code has a lot of dependencies and it can quickly get out of control without any "social" coordination.

umvi 7y ago
> and dozens of independent plugins for different purposes by different authors, all implementing a well-defined interface. Any new contributor adds stuff in parallel, without being blocked. This reminds me of Jenkins, which is the most nightmarish piece of software I've ever worked with. The plugins are of such wildly varying quality that it's hard to tell if something broke because of a plugin you just upgraded/installed, because the VM Jenkins is on got upgraded etc. And it's plugins all the way down. Plugins built on plugins. So if you try to file an issue with one plugin, they'll often just point you one plugin down the stack. You get what you pay for, I suppose, and obviously a lot of people like the tool.
- catalogia 7y ago
  Jenkins goes south because the people using the system aren't the people configuring the system. Consider instead a system like emacs, firefox, or mpv. Where the plugins/extensions/scripts are selected and configured by the person who's actually using them. Choosing what they want ignore what they don't, the result is a system that's understood by the person who actually uses it.
- m_mueller 7y ago
  As an aside, if you have a choice I recommend TeamCity. Much more fully baked than Jenkins - I needed zero plugins to set up the builds we needed.

umvi 7y ago

> and dozens of independent plugins for different purposes by different authors, all implementing a well-defined interface. Any new contributor adds stuff in parallel, without being blocked. This reminds me of Jenkins, which is the most nightmarish piece of software I've ever worked with. The plugins are of such wildly varying quality that it's hard to tell if something broke because of a plugin you just upgraded/installed, because the VM Jenkins is on got upgraded etc. And it's plugins all the way down. Plugins built on plugins. So if you try to file an issue with one plugin, they'll often just point you one plugin down the stack. You get what you pay for, I suppose, and obviously a lot of people like the tool.

catalogia 7y ago
Jenkins goes south because the people using the system aren't the people configuring the system. Consider instead a system like emacs, firefox, or mpv. Where the plugins/extensions/scripts are selected and configured by the person who's actually using them. Choosing what they want ignore what they don't, the result is a system that's understood by the person who actually uses it.
m_mueller 7y ago
As an aside, if you have a choice I recommend TeamCity. Much more fully baked than Jenkins - I needed zero plugins to set up the builds we needed.