ddulaney

There are definitely some benefits! Installation and updates become trivial. Also, collaboration is generally easier, because all you have to do is send a link.

These are the same reasons Google Docs took off, and they are real advantages.

Although, “let’s flush this out” is also a hunting idiom, as in flushing out game. So that may be part of the confusion.

Can I ask what hardware you’re using? I’ve heard similar things on the internet generally, but I’m on a several-years-old phone and it took under a second. Is the interstitial really that slow on some setups?

It’s fascinating to me what a different view of risk we had in the past.

The no damage being caused on the surface was a “new fact”. That would never fly today, for better or for worse.

The general cost over a several large codebases has been observed to be minimal. Yet, there are specific scenarios where the costs are real and observable. For those rare cases, an explicit opt-in to risky behavior makes sense.

Yeah, exactly. If you're a developer, it can take a little bit to figure out that "docs like code" is a really strange concept to lots of non-developers.

The idea of using the same tools to manage your docs as you manage your code only makes sense if you understand what tools you use to manage code! If you don't -- if your main experience with documentation tooling is Word, or maybe MadCap stuff -- that's a really huge leap to make.

I think the issue is that CSV parsing is really easy to screw up. You mentioned delimiter choice and escaping, and I’d add header presence/absence to that list.

There are at least 3 knobs to turn every time you want to parse a CSV file. There’s reasonably good tooling around this (for example, Python’s CSV module has 8 parser parameters that let you select stuff), but the fact that you have to worry about these details is itself a problem.

You said “handling data is complicated as much as the world itself is”, and I 100% agree. But the really hard part is understanding what the data means, what it describes. Every second spent on figuring out which CSV parsing option I have to change could be better spent actually thinking about the data.

If you even can with ASLR. Most modern boxes would disable stuff like this.

They just wanted the CLA to support the (paid) relicensing.

I think the reasoning (as it was explained to me) was that when people made their original contributions, they were agreeing to the license at that time (in this case GPL, but for other projects MIT). But the other contributors never agreed that the main maintainer could relicense their contributions for a fee.

The upshot was that we went with an in-house fully-proprietary alternative. More expensive, probably lower quality.

I don’t think it would’ve in our case, at least. I actually quite like our OSS policy: basically, we don’t want to be in the business of maintaining forks, so all changes should try to get upstreamed if at all possible. It‘s good client service as well: when our clients ask about the libraries we use, we’d much rather be able to tell them “the latest public version” than “here’s our fork”.

We also want to engage with and donate to the projects we use, mostly out of risk management: if they go unmaintained that’s bad for us.

We (engineers) actually wanted to for another GPL’d project! But because they didn’t have a CLA, the lawyers wouldn’t sign off on it — they decided that the main/current maintainer didn’t have the rights to relicense it for us.

We probably would’ve for LZO too; not sure why that fell through.