In contrast, Nix trivially gives awesome tools for patching in fixes at varying degrees of locality, making it very easy to maintain a long term fork or just apply unmerged fixes in the short term.
Anyway, I haven't used PHP in fifteen years, but it's great to know that it at least attempts to address this in a better way. Certainly project/dependency-level package managers should have a major advantage over distro package managers in terms of being able to address this kind of thing, but it seems that many of them still ended up with distro-packaging conventions and concepts baked deep into the design.
No, it’s not ok. I did that of cause, but it’s not ok, it’s bad. Especially when you promised something to people using your code. Not much effort is required to drop a one line notice - find the internal strength to do it please.
THIS SOFTWARE IS PROVIDED „AS IS“ AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
“Never” is a very strong word. What is your recommendation based upon, exactly?
This is my code. It costs me nothing to tell people my future plans with the code. It costs me nothing to tell people that my plans are most probably off. But it will gain people something - they would be able to plan for the future better.
“Politeness costs nothing and gains everything” - is a better theorem (than yours one). I would rather tell it as: politeness usually costs nothing and gains at least something, but that’s just an engineer correcting a salesman’s statement.
But your plans can change.
Maybe you change your priorities, maybe you discover that a feature is harder to implement than what you tought and you must reduce its scope.
Or maybe you realize it was a bad idea after all and decide to implement a different feature.
If you have promise the original feature, instead of happy users for the improvement, some of them will be angry because of what you "took from them".
That's why I think the real politeness is to never promise nothing concrete until you are actually ready to ship it.
2. But. Even in a socialist country there is always a bunch of people who love their job more than a paycheck. Let’s call them “real professionals”. They just love to get things done.
3. When a real professional comes to a capitalist country he sees that there is a huge demand for their services and no real competition. Cause a lot of capable people virtually disappear whenever they damn well please unless they are paid _extremely generously_ for their work. For example:
4. Our customer was complaining that they have too many problems with our software. I was sent to look into that. When I arrived their CTO demonstratively unscrewed the plate with the name of our company from the door of the room I was assigned to. Shrug. Working. Issue #1, issue #2, … issue #23. Sound customers hear while connecting through our switch goes up, then down, then up, then down… Investigation revealed that one department under the CTO bought their voice files from one vendor, the other department under the CTO bought their files from another vendor. One bunch was twice as loud as another.
Now, neither vendor was going to do anything about that unless they are paid extremely well for the additional job. Neither department was going to do anything about their files unless they are paid extremely well for their work (actually they were demanding each other blood, but you can consider it just a kind of currency). I scratched my head. It is definitely not our job, we just connect a source to a destination. But. Actually our software can see which department a voice file comes from. I am going to give you an option: based on a voice file source you will be able to adjust the volume by a configured amount. And this configuration can be changed in real time, so basically you will have a volume knob you can adjust while software runs.
It took 15 minutes to code and a week of QA, which does not count since it is always a week of QA. Anyway in a week issue #23 was gone. Next.
In four months the CTO told me that in 15 years in the tech industry he never saw a company as aggressive as ours. The definition “aggressive” gave me a pause. Nothing we did seemed “aggressive” to me. We humbly listened to the problems and did our best to help, without sorting “our problem” or “not our problem”. It’s kind of opposite to “aggressive”, no?
5. A customer from that F..<something> list of big companies that is often thrown around but I could not remember it exactly told me once that when something happens, they pray (as in pray to God) that it was our company fault. Or, if not - that we were able to find a workaround.
—-
So of cause, go ahead - disappear unless you are paid extremely well for your work. Even if that work is dropping a line warning people that your plans have changed. Such a widespread attitude gets me paid extremely well. Kinda ironic, no?
Still, if you want to force me to do absolutely anything on a project I maintain myself and for fun, feel free to pay me extremely well. My employer does so and gets my work, the price doubles for anything done on my free time.
Lol. I have a “living experience” both in socialism and in dismantling it, which is an extremely painful experience in itself. My points 1 and 2 are from hands-on observation.
And my naming something a good thing is not the same as me forcing you to do that good thing. Yes, a named a politeness a good thing, but this declaration while obviously true can’t force you to be polite. Confusing these two things is a logical slippage. Frankly, I never observed such a slippage in good professionals.
That's it, and I can refer HR departments that enjoy reading github profiles to that pile of code with various levels of quality.
Nothing else and I post all my own code as GPL unless forced otherwise by existing licenses.
I do not work for others for free.
apt-get source xxxx
put patch in debian/patches
dch --increase
dpkg-buildpackage.
Copy the patch and rebuild next time a new version comes out.
Easy on Gentoo - https://wiki.gentoo.org/wiki//etc/portage/patches
Don't build FOSS for others. Build it for yourself and package it for others. Expect contributions. It's okay to expect your users to contribute. It's okay to push back and expect them to contribute. It's okay to say no to PRS because you don't have time to review them. It's okay to not have the time to say you don't have the time.
Personally, package management solutions fall short of the FOSS goal for me. Hard to start with a package and float my own changes. Hard to fork and maintain my own version. The whole push for staying on mainline and pushing that burden of the original author is a symptom IMO.