the court can remain unconvinced longer than you can stay solvent
106 karma · joined May 24, 2013
We can agree the discussion could be handled better, and the accusations were unwarranted in context; I happily chalk that up to a misunderstanding (rms not seeing other people's lack of awareness of value framework incompatibility as a massive obstacle to conversation, instead assuming interlocutors had better information than they seemed to, in which case their behavior could have been construed as being in bad faith) - which implies 2015 rms should probably dial it down in the strength of his accusations among other adjustments. Communication is _not_ easy.
If a farmer and a forest ranger go into a patch of land, they will see the same scenery, but may have heated discussions about what to do with it. Unless they understand that one of them wants to produce food, and the other to protect the forest. And if one of them has decision-making power over the terrain, even if they have not been in there personally for a while - the argument about how what they want to do fits with the decision-maker's values needs to be made.
Of course, nobody is stopping the developers from going and doing the stuff they want to do in the first place, distributing it and, if the change is as technically important as it seems and the cards are played just right, even becoming the de-facto standard distribution of a piece of software; their changes just won't be merged into the main product for the foreseeable future.
I am very emphatically not making any statements about the technical aspects of gnu software.
The FSF is not the same as the gnu project, even if they share a lot of values - since they're being used mostly interchangeably in this post, let's roll 'em into one.
Whether someone is good or not for an organization can't be evaluated against arbitrary values: they evaluation needs to be made against the organization's values and their current state.
It's the same issue as when people were complaining about the AST not being available to make emacs _customizable_ into a better C++ IDE. Before even thinking about the technical merits of the solution, the questions that need to be answered unequivocally look like: "Are we making it easier to create non-free software from our work if we do this?" or "Are we eliminating leverage that incentivizes people to write free software in this are?"
From the FSF's standpoint, The crucial questions like "Are we enabling amazing software?" or "Are we going to gain market share from this?" are _secondary_.
And much of people's teeth-grinding is because they don't understand that; at least in the AST discussion I noticed that people arguing for the AST didn't appear to see that their priorities weren't the same as the gnu project's, and rms seems to not have noticed the discrepancy (or attributed it to plausible malice) and made some very strong accusations to people who just weren't arguing their side from the appropriate value framework. Appropriate because gcc is a gnu project, therefore its roadmap is decided according to gnu's values.
If you can't see this, you can't understand that some features, desirable as they could be, should not be (from their standpoint) implemented; from their standpoint, pursuit of technical excellence, usefulness, market share, beauty - any other feature that a software project may have - is subordinated to the value of software freedom.
You may or may not agree with that, and that's OK; but an org that has that kind of value framework sure needs someone - not rms specifically, mind you - who shares it, or at least understands it thoroughly and can commit to making organizational decisions based wholly on that value structure.
We can take this as a given for the purposes of the discussion.
> They are intertwined
But which has priority?
The main issue with this topic is that it's sometimes hard to see things from an angle we're so unaccustomed to.
The FSF and the GNU project are accidentally technical, morally-driven organizations. Technical superiority is never the argument for Free Software. You may be thinking about Open Source and mixing them up.
Try to see it from that point of view: if an organization exists to prevent "some evil" from happening and make it as easily as possible for "good people" to not commit and not be subjected to "that evil", it makes sense that the organization will sacrifice things that don't seem to make sense because they are avoiding as strongly as they can to make "some evil" easier to commit.
The goal is not market share; the goal is not technical superiority; the goal is not profit; the goal is to "not be evil", help others "not be evil" and not make it easier than it ever needs to be to "be evil".
Look at the "about" pages in the FSF & Gnu project websites and you will notice that it is not a bad choice for them to avoid doing some things "for market share" or "to remain competitive" when those clash with creating free software, making it easier to create free software, and make sure (within the realm of possibility) that their work cannot be used to facilitate the building of non-free software.
From the FSF's point of view loss of market share is an acceptable loss, if the alternative is "be evil". That is why, odd as it may seem, the FSF needs someone who does not compromise on that.
On technical matters, you are correct; on moral matters it's a different story.
Think about the moral tragedies of history; we didn't need someone saying "maybe we should not be so evil; let's be less evil - not stop, because that's disruptive and I am not an extremist, but maybe dial it down a bit?"
On moral battlegrounds we need someone capable of saying "we have to stop, and no price is too high to pay in order to stop being evil". Someone who is willing to pay the price themselves, and make the price as low as possible for anyone that wishes to follow through. Nothing less than that suffices; "They enslave their children's children who make compromise with sin", to say it poetically.
You're mixing things here. :) meritocracy and decentralization are completely orthogonal to free software. They [edit: s/are/could be construed as a/] part of the open-source ethos as explored in CATB & explained by esr, not a sine-qua-non of free software.
The detail to look at is that flexibility is a feature of the cloud offering, and an expensive one at that. If you don't need it, you need to find a way to not pay for it.
You'd want to co-locate with ISP who already has infrastructure for continuous services through blackouts et al, or you could have a datacenter if it's small-ish, because you already have some infrastructure to keep operating during blackouts.
https://docs.firefly-iii.org/en/latest/import/ynab.html
--- EDIT: misread! I don't know about the _features_. They support importing, which doesn't imply supporting the features.
You can create pipelines that save labor - like clients for platforms that make answering common questions / interacting with users way more comfortable and suited to your targeted workflow than the default clients.
On the creativity front, you can also generate random, semi-plausible stuff to inspire you when you're in a rut.
It's not quite about making everything automated, but about leveraging code, systems thinking, and collaborators in such a way that your performance is incredible. It's really feasible.
I'm curious because this would be the difference between "scale with more cores" or "scale with more NICs".
If one of my prod servers were forcefully updated - with no warning, therefore no chance to make backups - I'd be furious. If my main dev machine was bricked as a result of forceful updates, as I seem to recall it happened to some folk...
It feels like they disregard users in that sense, and it's sad.
Cuba & Venezuela are not within the normalcy of LatAm - different economic models, different politics. Mexico has good abortion laws - at least in the capital.
There are awful abortion rights records. Agreed - even in my own country, where we're fighting to have it allowed at least for extreme cases (nonviable fetus, or situations that put the mother at big risk, like ectopic pregnancies). Most LatAm countries at least allow abortion to save the mother's life.
Agreed that there's not been enough support to effect changes to the laws. It's an uphill battle; most of America is historically very right-leaning; military dictatorships and rights infringement were the norm for most of the 20th century in much of the subcontinent, and people who lived - but mostly those who _grew up_ - through that have the lingering effects of those predispositions.
But - yeah, the left is generally out of the circles of power in LatAm, and the laws - in particular abortion and other religion-endorsed observations - are very right leaning.
I am a Latin American and can say it's just not so - at least in the countries I know, the left is usually pushing for more sex ed, and more availability of abortion.
It'd be interesting to know _where_ in Latin America the left favors the restrictions on abortion - at least to document that perspective and share it around.
But building a proof-of-concept in my branch is way less invasive. I've bought many a candy bar to people who've proven me wrong. And he seems to have done things by the book (do the work, take the measurements).
On the other hand, can't agree more with the coaching - and that's what pains me. Sometimes people in leadership positions aren't as strong in leadership skills as they could be.
Nothing is more delightful for me than having someone prove that things that could've taken a month can be done in a week with no sacrifices - means we've low hanging fruit and can devote time to improving _more_ things in the time we've available. Maybe even write pretty documentation or other things that are usually neglected.
I must say, though - I've seen that "this is going to take forever!", "this is _SO_ complicated!", and "we'll have to code A LOT for this!" attitude before. So much so, that the very wording makes me suspicious. When I see that in an org - as opposed to "with this timeline, we'd have to change the scope so and so to deliver", or "Let's make sure we achieve what we want", or - basically, there are wordings that match what you'd do were you playing victim, and wordings that match what you'd do if you were a competent person doing their best for the company.
> The Steve Blank article Brilliant. I've learned similar from watching my own father _learn_ that :^) I recommend using Monica (monicahq.com) and applying those lessons in all areas of life.
Bad habits are contagious, momentum gets lost. Conformity is a strong force.
I've been lucky to have great leadership to learn from and model, and who've taken time to guide me through why things couldn't be fixed at a certain point in time - or plain asked for patience and scheduled time to devote to my concerns.
Given good developers are pretty much in demand, I think we can afford to stay true to ourselves most of the time and just shop around for leadership that suits our style.
But being in leadership and spending time around a few hundred coders over the hears has taught me the value of someone who does this.
I hope this wasn't the reason the person was fired, because it's a missed opportunity for management: someone with that kind of drive and commitment to quality is valuable to have - and hard to find. I can count with my hands the number of developers with that kind of drive I've found.
With no further context - meaning: I'm making a lot of assumptions here - I think I'd've helped them schedule time to evaluate these opportunities for improvement (how much do they cost to fix? how much will they cost if not fixed? How can we prevent this from getting in new code? etc.), and when the numbers are right - schedule time for fixing them, too.
If non-agreeableness was their sole defect - it could've been worked on over time. That's what leaders are there for: to help their collaborators grow.
Look for something interesting to do, start doing it, educate yourself in it, and start trying to get paid for it. Learn the rules of the game you want to play.
You may want to become an accountant, for instance. There are clear steps to doing that.
I daresay you should first find a destination, so you can then look for the steps needed to get there.
I don't really understand. I never paid a license to create and distribute native applications.
And I offered to do the work necessary on my own time on both these occasions, with safeguards so we could fall back into the status quo at the slightest signal of trouble.
So no, while I can be - and am - passionate about new tech, I cut my teeth developing large scale systems that had to be up at all times. So being conservative at work is second nature to me, even if I play with unstable or experimental stuff all the time.
It's... not cool that you tried to be clairvoyant instead of curious.
Maybe in the future you could ask "How did that turn out though? Were the systems changed, that you know of? Did you consider that management didn't want the team to waste the org's money trying to be purists or over-engineering? Did the decision maker have a technical background?" or other such questions, in order to later make an informed statement.
On the other hand, the way you stated it made me think you've had an awesome experience with great management, so congrats on that, I hope you keep choosing amazing teams to join - if or when you change gigs :^)