Thomas Depierre
@smxi I would point out that I am not asking for money.
I am stating the reality. I doubt money will help that much or that it could be sustainable.
What I am saying is that you cannot make me a supplier and you need to accept that. Stop bending the world to your view. Accept it as it is and find out what to do from there.
Also. I am definitely not someone that would advise to focus on Free vs Open.
Thomas Depierre
@clacke @smxi It is not discussed a lot because it mostly does not work.
The most obvious aspect is that they use open source precisely to avoid having to deal with the legal and procurement journey because it is slow and painful, and no one wants to talk to procurement.
The less obvious fact is that you cannot sustainably maintain most of these projects this way. You cannot get a vendor for long. And you cannot hardfork them, because maintaining them necessitate an expertise you cannot hire
Santa Claes πΈπͺππ°π
... So: Commercial software vendors can repackage upstream, they can softfork upstream, if necessary they can hardfork upstream, and if people want their supply chain they can find a vendor willing to do it in one of these ways. I'm surprised this route isn't discussed very loudly every time this kind of exploit is made.
Santa Claes πΈπͺππ°π
Santa Claes πΈπͺππ°π
Many bigger projects, especially stuff in the circles near the Cloud Native Computing Foundation, have distros of open projects.
Just want to run OpenStack and Kubernetes, or want to contribute changes? Get it from upstream, work with upstream.
Want an SLA, an SBOM, support etc? Buy a distro from a commercial vendor. Upstream will get fixes in the pace that works for upstream and distros provide whatever their clients want to pay for.
To call it a product distro is appropriate, because community OS distros like Debian and Fedora do this too, they don't just package things, they also track bugs and act as a first-level support line, they backport fixes, etc, and when appropriate it all bubbles up to upstream, which can stay focused on the latest version and the upstream product vision. And of course commercial distros like RHEL do this too, or perhaps even more so, and are definitely willing to sell the service of doing so.
valhalla
@clacke for some things, I think that paying people to work inside existing distributions can also work; it is e.g. already possible to pay somebody to work on maintaining specific debian packages past the time the official support for a certain release has ended (and probably also way past the official *upstream* support has ended).
It has to be managed carefully, but I believe that Freexian / Debian LTS is a good example which could apply to other cases (and is probably completely not suitable for others).
The main advantage here would be that the results of such paid work would be available also for other people, and thus they could be less expensive for each individual customer.
Santa Claes πΈπͺππ°π
@valhalla This is awesome! First time I hear of it.
Yet another "if you think of it, someone on the internet did it". This is exactly what I'm talking about.
freexian.com/lts/debian/detailβ¦
"Several Debian developers who are willing to provide security updates for Debian on a paid basis got together and created the service presented on this page. Freexian, a French company managed by 3 Debian developers, collects money from all parties willing to financially support the LTS effort, and uses this money to pay the Debian contributors who are providing security updates."
π€©
smxi
@clacke @Di4na In terms of hiring, I think I follow with Thomas D, I am NOT a supplier. I have zero interest in damaging my code to make it work around bugs created by a billion dollar corporation (yes, looking at ibm-redhat). Nor am I interested in their problem set unless it directly matches what I want the software to do for its users. And no, corporations are NOT users, they are legal fictions assembled to funnel capital, and generate profit. And I don't volunteer for that, at any price.
Santa Claes πΈπͺππ°π
@smxi So you don't. You do you. And someone else who accepts money for gnome work shields you from the people inside the capital funnel machinery who want a supply chain.
If you're worried about code pollution from corporate concerns, the gnomes can look at how OpenSSH does it as a model: The upstream is clean and OpenBSD-specific, and then there's a downstream distro that adds abstractions and adaptations to make OpenSSH run on GNU, POSIX and elsewhere.
smxi
@clacke @Di4na Basically, if you want me to deal with boring problems that I'd never ever dream of touching in my free time, then yes, pay me, and I'll get those working for you, wincing at the stupidity of the problem in terms of the bigger world. But if it's for me, I am going to write it the way I want, to solve the problems I (and positive people I respect from experience) want, and make the code as good as I can make it, which can take up to 10x longer to do than with commercial code.
Santa Claes πΈπͺππ°π
@smxi @Di4na That's the "if you are not interested, [they can] hire someone else" part of what I said.
Don't push duties on original authors. Pay *someone* to dot the Is and cross the Ts and whatever else corporate risk analysis requires.
Chirp! is a social network. It runs on GNU social, version 2.0.1-beta0, available under the GNU Affero General Public License.
All Chirp! content and data are available under the Creative Commons Attribution 3.0 license.