Salta al contenuto principale


Excellent article: I am NOT A SUPPLIER!
softwaremaxims.com/blog/not-a-…

You are all on the hobbiest maintainers turf now
softwaremaxims.com/blog/open-s…

This guy nails it. If you want me to be your supplier then pay me. Period. Most of this comes from a pathological corporate mindset where sociopathic greed is considered normal. Plus a failure to read the licenses in first place: #gpl: software supplied with no warranty of fitness, not even implicit.

Focus more on #FreeSoftware and less on Open.

Questa voce è stata modificata (7 mesi fa)
in reply to 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.

in reply to Thomas Depierre

@Thomas Depierre @smxi What I'm taking away is, not because you're saying it, but because it's my conclusion, is that if people want a supplier, they can either ask you the original author, or if you are not interested, hire someone else to do whatever compliance work they want done.
in reply to clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

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.

in reply to clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

... 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.

@smxi @Thomas Depierre

in reply to clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

@clacke 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

in reply to Thomas Depierre

@Thomas Depierre @smxi Good points, and true for most companies.

But then you also have companies who desperately want to pay someone but don't know who and how. Maybe not enough of them.

#tidelift obviously is trying to cater to those companies, and it's not unsuccessful, but also not the smashing success that I'd want it to be.

And what I'm talking not is not exactly Tidelift, which takes more of a facilitator approach rather than a vendor approach.

Maybe not everything can be covered by Tidelift-but-vendor, but I'd like to think there is a missed opportunity with some core projects for which this would work better than Tidelift or foundations financing grants.

in reply to clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

@clacke I mean the problem is also on the other side.

As a maintainer, i cannot take that supplier posture except if i have a quite high and stable income.

I need at least 80% of my salary income coming from it in a stable way before i can spend more time on it. Paying me does not help under that.

Because I cannot find the time. I have a job. Family. Pets. A house. Friends. Hobbies.

I cannot cut them sustainably. The only thing that can be cut is my work. And it is inflexible

in reply to Thomas Depierre

@Thomas Depierre @smxi That's exactly where the third-party vendor makes sense. Focus on what interests you, and a business charges people and takes care of the "boring" stuff, the supplier role.

(Personally I'm super excited by the "boring" stuff and would love to work for this fictional "Code Gnomes Inc" company)

Where the model falls down, apart from the obvious issue of finding people who want to pay, is, as you pointed out, if the problem domain and intrinsic complexity make the supplier parts difficult for anyone other than the deeply skilled original author to manage.

If that's the truest for the projects that would need help the most, that could be why nobody else is talking about this.

in reply to Thomas Depierre

@clacke And that makes a tall step from zero to being able to take money in. A step that cannot be met easily by a few companies wanting a cheap vendor support.
in reply to Thomas Depierre

@Thomas Depierre @smxi There has to be a critical mass of demand for a commercial supplier, for sure. If nobody is demanding it, any attempt to provide it is doomed.
in reply to clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

If all the companies that claim to want a supplier would be willing to put their money where their mouth is, there would be a market for #CodeGnomesInc to partner with and shield the maintainer rather than to add to their burden.

If people are just trying to add duties to existing maintainers, those people can get lost and get back when they have something to contribute.

@smxi @Thomas Depierre

in reply to clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

@clacke: inhibited exhausted pixie dream boy 🇸🇪🇭🇰💙💛 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.

in reply to Elena ``of Valhalla''

@Elena ``of 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."

🤩

in reply to clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

So, anyone who wants a Debian supplier can just jump on this and that's exactly what they get.

"Any contribution gives you the right to submit a list of packages that you rely on, and that should be prioritized in terms of security support."

"If your funding level is at least Bronze 1, Freexian will subscribe the person listed as technical contact to a private mailing list that all contributing companies can use to discuss their needs and share their experience."

"If your funding level is at least Silver 1, you can submit your queries and requests about Debian LTS in general and/or any security update in particular to us."

"If your funding level is Platinum, you can submit to us functional tests covering the set of packages that you care about, and we will run those tests on updated packages to detect undesired regressions"

#Freexian #DebianLts

@smxi @Thomas Depierre

in reply to clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

@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.
in reply to smxi

@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.

@Thomas Depierre

in reply to 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.
in reply to smxi

@smxi @Thomas Depierre 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.

in reply to smxi

if at least developers used #GPL / #AGPL, the corporations at least were forced to contribute back in one way or an other, but due to the rampant use of MIT and BSD licenses, they can literally get away without doing anything beneficial for the wider ecosystem while using other people's code (those other people let them do it).

I think the proliferation of MIT and BSD licenses really made the #FreeSoftware free rider problem much worse than it should be.

in reply to NiceMicro

@nicemicro valid use cases for bsd type licenses: single project (apache,nginx,openssh) where priority is get that tech into everything. Outside those you are working for free for corporations who will never give back. Truly freed code survives because you can't steal it without obligation. This stopped being a debate years ago:
#Gpl: linux,libreoffice,khtml>applewebkit>blink
Bsd/mit: Bsds,openoffice,mozilla

It's funny to see people pretend this is a debate when success of gpl transparent.

in reply to smxi

I think that the huge rate of burnout in developers that cause issues time and time again can be traced back to this attitude of "I will license it permissively to get it into everything". When the code gets into everything without compensation, the pressure of responsibility mounts, and bad things happen.

It is my personal belief that one's mental health doesn't worth the "bragging right" of one's code getting into a wide range of proprietary garbage.

#FreeSoftware #GPL

in reply to NiceMicro

@nicemicro to me the core mindbug is open source. Vs #FreeSoftware. If you fall for that trap then one license is as good as another so you'll burn out once reality sets in. I make free software to help the bits of free software ecosystem I can. Free software of course is open source by definition but as ibm-redhat recently showed us the contrary is not necessarily true. Since I've never had any interest in doing unpaid work for billion dollar corporations I used gpl from first day I found it.
in reply to smxi

@nicemicro Any company that avoids #gpl is openly admitting they want to take without giving back. Those are not desirable partners long term as has been proved over and over. Nor are they reliable or trustworthy. Every gpl project has a possible long term future builtin and every non enforced sharing license project can go like a poof of smoke because it has no true code permanence protection beyond last public commit. Like rhel is trying to do while stealing our code to use their stupid word
Questa voce è stata modificata (7 mesi fa)
in reply to smxi

honestly, I don't really mind that much what RedHat is doing. No one is entitled to get updates to a software from you just because you gave them an earlier version.

As long as they don't restrict your GPL guaranteed rights for the software itself, they can condition the future business relationship with their customers on whatever they want.

in reply to NiceMicro

@NiceMicro You seem to be referring to how Red Hat conducted business before they shut down CentOS 8/9.

With their current setup, you as a paying customer get the binary packages, but you don't get the Complete and Corresponding Source Code for your packages.

All you get from them is "[it all comes from the git repos for CentOS Stream, some commits in there, you'll figure it out]". In theory you can find the information, but it's obscured for no reason other than obscuring.

If you redistribute what you got from them, as the GPL requires them to give you the right to do, they will terminate your support contract and access.

@smxi

in reply to clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

@clacke I don't think what you describe here is correct. I think what you describe here is true for their publicly available repositories. As a customer you have the right to ask for the exact source code that your binary packages were compiled from, and I am not aware of any instance of them not honoring them.
in reply to NiceMicro

@clacke The GPL does not have any clause that makes a user entitled to any future versions or any tech support.

Therefore, it is not a violation of the GPL to terminate business relationship based on an action that is allowed by the license but not allowed by the business agreement.

Red Hat can't come and take away the code they already gave you, and can't stop you redistributing it. They have all the rights to not talk to you any more though.

in reply to NiceMicro

@NiceMicro @smxi If the license requires them to allow redistribution, and if they ensure redistribution has negative consequences, then a reasonable bystander would say they are not allowing redistribution, but are in effect imposing "further restrictions".

But nobody has gone to court over it yet.

Questo sito utilizza cookie per riconosce gli utenti loggati e quelli che tornano a visitare. Proseguendo la navigazione su questo sito, accetti l'utilizzo di questi cookie.