5 ms·

I work on one of those FLOSS projects that has several ostensibly-open-but-only-works-on-the-proprietary-instance sort of features baked into the core codebase.

I work on one of those FLOSS projects that has several ostensibly-open-but-only-works-on-the-proprietary-instance sort of features baked into the core codebase. Some of them are dilutive, but some of them are actively subtractive, especially when they impact performance, become a blocking point during library upgrades, confuse our users, and generally make the codebase harder to reason about. This code is essentially dead code in the community offering, and we all know that dead code is not neutral, it's a liability. Fortunately, our project is moving in the opposite direction than the one that the article describes: we have an independent steering committee & well-funded core team now, and lately have been actively trying to boot proprietary features out of the core offering. But it's a lot of work, both technically and socially, and we'd have much more time to spend on new features if it weren't for the dead weight we have to deal with.

JJMcJ 3y ago
More than one FLOSS developer has written of huge companies with thousands of programmers working for them practically crying and begging to have a feature added to software that serves only the company's interest. Or even replying that they are busy with other things but if the company wants to pay for the change they can work on it, and company replying that that seems like "extortion", as if the developer is under moral obligation to fix Initrode's problems for free by the end of the week.
- kdmccormick 3y ago
  Yeah, our situation isn't quite that bad. The big company is happy to write the feature usually, but that doesn't mean the feature should be bolted into the main repo with its special dependencies dropped right into setup.py install_requires.
- ThrowawayR2 3y ago
  > "...huge companies with thousands of programmers working for them practically crying and begging to have a feature added to software..." One clueless employee, almost certainly without the knowledge of his cow-orkers or managers let alone any kind of authorization to represent their employer when communicating externally, writes a dumb email to a FOSS project and suddenly the tech commentariat is all abuzz about "$BIGCORP (the whole thing) is 'practically crying and begging' to $FOSS_PROJECT for a feature"? Surely there must be a name for this fallacy and, if not, there should be. The organizational hivemind fallacy perhaps?
  - JJMcJ 3y ago
    Many mega corps have a culture of bullying the vendors. That can easily spill over to a single interaction.
    - ThrowawayR2 3y ago
      Yeah but the point is that megacorps have dedicated teams of specialists to do that kind of bullying and they do it with organizational consensus and coordination between relevant departments. No random individual engineer is ever going to be authorized to do that.
      - JJMcJ 3y ago
        What I meant was that when an engineering group needs a fix from a FOSS developer, the natural thing to do is to bully and beg. One reason beside bad culture is another aspect of bad culture. If they want a fix to a piece of FOSS, probably a library, they might have to beg their management for weeks or months, instead of just specifying that their project requires lib-from-overworked-dev-in-Nebraska-who-is-thinking-of-taking-up-alpaca-ranching-instead version 2.44 or later, which is what they can get if they beg, cry, and/or bully said alpaca contemplating developer.
dtaht 3y ago
I would be very interested in learning how to go about getting a well funded core team for an open source project (libreqos.io). We are increasingly popular, but still lack a business model. I too tend to reject most friction-creating and value-subtracting processes, but the top ramen is running low.
- specialist 3y ago
  When you find out, please share. There's dozens of us. I've been slow walking my FOSS releases because I have no idea how to squeeze some ramen out of it. Though my (dare I suggest) paradigm/category busting project was really hard (for me) to figure out, the end result is simplicity itself. And so therefore trivial to clone, fork, run away. Possessing the business acumen of plankton, I've been swindled, plagiarized, and mooted a few times before. I don't need much more than ramen money. But not getting anything while others profit from my work, again, would really suck.
  - pombreda 3y ago
    You should not do FOSS if you do not want to make a gift, with few strings attached --if any. Use a proprietary license instead :]
    - specialist 3y ago
      Interesting. Where can I read more about FOSS as gifts?
- kdmccormick 3y ago
  Happy to share, although I don't know how applicable the journey is to most. The project started as nonprofit with both a business goal (sustain itself by selling online courses) and a philanthropic vision (essentially: increase education access by disrupting the degree market & also open sourcing the code). A decade later, the nonprofit sold the entire online course business, its brand, and most of its staffing to a for-profit company. It kept the copyright to the open source code, and the remaining staff now use the proceeds of the deal as an endowment to pusue the original philanthropic mission, which includes being a sort of core team for that open source code. Some details [0]. The online course business is edx.org, the buyer was 2U, the source code is Open edX [1] and the nonprofit started as edX Inc and was renamed to Axim [2] after the sale. 0. https://press.edx.org/2u-inc.-and-edx-complete-industry-redefining-combination https://press.edx.org/2u-inc.-and-edx-complete-industry-rede... 1. http://github.com/openedx http://github.com/openedx 2. http://axim.org http://axim.org TL;DR: Start off as a nonprofit, build a valuable product, sell the product, and then use the money to continue the nonprofit. YMMV ;) EDIT: Probably obvious, but I should note that this didn't all just "happen"--there were (and are) extremely passionate people on both sides of the sale and in the project's open source community who worked hard & advocated loudly for years, ensuring that both the nonprofit built a compelling product and the open source project thrived. Both of those were critical ingredients in the project getting to its current well-funded state.

JJMcJ 3y ago

More than one FLOSS developer has written of huge companies with thousands of programmers working for them practically crying and begging to have a feature added to software that serves only the company's interest. Or even replying that they are busy with other things but if the company wants to pay for the change they can work on it, and company replying that that seems like "extortion", as if the developer is under moral obligation to fix Initrode's problems for free by the end of the week.

kdmccormick 3y ago
Yeah, our situation isn't quite that bad. The big company is happy to write the feature usually, but that doesn't mean the feature should be bolted into the main repo with its special dependencies dropped right into setup.py install_requires.
ThrowawayR2 3y ago
> "...huge companies with thousands of programmers working for them practically crying and begging to have a feature added to software..." One clueless employee, almost certainly without the knowledge of his cow-orkers or managers let alone any kind of authorization to represent their employer when communicating externally, writes a dumb email to a FOSS project and suddenly the tech commentariat is all abuzz about "$BIGCORP (the whole thing) is 'practically crying and begging' to $FOSS_PROJECT for a feature"? Surely there must be a name for this fallacy and, if not, there should be. The organizational hivemind fallacy perhaps?
- JJMcJ 3y ago
  Many mega corps have a culture of bullying the vendors. That can easily spill over to a single interaction.
  - ThrowawayR2 3y ago
    Yeah but the point is that megacorps have dedicated teams of specialists to do that kind of bullying and they do it with organizational consensus and coordination between relevant departments. No random individual engineer is ever going to be authorized to do that.
    - JJMcJ 3y ago
      What I meant was that when an engineering group needs a fix from a FOSS developer, the natural thing to do is to bully and beg. One reason beside bad culture is another aspect of bad culture. If they want a fix to a piece of FOSS, probably a library, they might have to beg their management for weeks or months, instead of just specifying that their project requires lib-from-overworked-dev-in-Nebraska-who-is-thinking-of-taking-up-alpaca-ranching-instead version 2.44 or later, which is what they can get if they beg, cry, and/or bully said alpaca contemplating developer.

dtaht 3y ago

I would be very interested in learning how to go about getting a well funded core team for an open source project (libreqos.io). We are increasingly popular, but still lack a business model. I too tend to reject most friction-creating and value-subtracting processes, but the top ramen is running low.

specialist 3y ago
When you find out, please share. There's dozens of us. I've been slow walking my FOSS releases because I have no idea how to squeeze some ramen out of it. Though my (dare I suggest) paradigm/category busting project was really hard (for me) to figure out, the end result is simplicity itself. And so therefore trivial to clone, fork, run away. Possessing the business acumen of plankton, I've been swindled, plagiarized, and mooted a few times before. I don't need much more than ramen money. But not getting anything while others profit from my work, again, would really suck.
- pombreda 3y ago
  You should not do FOSS if you do not want to make a gift, with few strings attached --if any. Use a proprietary license instead :]
  - specialist 3y ago
    Interesting. Where can I read more about FOSS as gifts?
kdmccormick 3y ago
Happy to share, although I don't know how applicable the journey is to most. The project started as nonprofit with both a business goal (sustain itself by selling online courses) and a philanthropic vision (essentially: increase education access by disrupting the degree market & also open sourcing the code). A decade later, the nonprofit sold the entire online course business, its brand, and most of its staffing to a for-profit company. It kept the copyright to the open source code, and the remaining staff now use the proceeds of the deal as an endowment to pusue the original philanthropic mission, which includes being a sort of core team for that open source code. Some details [0]. The online course business is edx.org, the buyer was 2U, the source code is Open edX [1] and the nonprofit started as edX Inc and was renamed to Axim [2] after the sale. 0. https://press.edx.org/2u-inc.-and-edx-complete-industry-redefining-combination https://press.edx.org/2u-inc.-and-edx-complete-industry-rede... 1. http://github.com/openedx http://github.com/openedx 2. http://axim.org http://axim.org TL;DR: Start off as a nonprofit, build a valuable product, sell the product, and then use the money to continue the nonprofit. YMMV ;) EDIT: Probably obvious, but I should note that this didn't all just "happen"--there were (and are) extremely passionate people on both sides of the sale and in the project's open source community who worked hard & advocated loudly for years, ensuring that both the nonprofit built a compelling product and the open source project thrived. Both of those were critical ingredients in the project getting to its current well-funded state.