Threads for danpalmer
-
Part of this gets to a core cognitive bias that is quite pervasive among software engineers – that self-hosting/self-managing/etc is better.
I think this comes from a few places:
- We like control
- We like “simplicity”, and knowing all the moving parts feels simpler than some big black box
- Many of us like our craft enough that it’s a hobby, and when in hobby-mode having an extra thing to do is often a positive rather than a negative. Open-source contributions are often done in hobby-mode.
For professional open-source maintainers though it’s a lot more like consulting or working in a bigger company, there are priorities, and opportunity cost is a cost, as we are accountable to others in a way that hobbies aren’t. In addition, spending money for someone else to solve a problem cheaper than you can is good business.
I certainly suffer from this bias sometimes, but I do my best to identify it at work, and also to identify when others may be in work mode even if I’m in hobby mode. I’ve also found that treating the development I do “for fun” closer to that which I do at work brings a number of benefits!
-
It’s also that we like independence. Being dependent on others is always going to be a liability in some sense. Especially if they’re a corporation with a closed, centralised platform.
I think the normalisation of censorship we’re seeing in 2021 is proof of that, whatever your opinion of that may be.
-
-
You make a good point about censorship, although I think the average company or open source project taking this into account may be an overreaction.
On the one hand, we’ve seen very few examples of companies/people being denied service in this way, and only for very egregious examples that have hit mainstream media in the US with a wide public audience. This suggests that most of us (non-US, those not inciting coups, etc) have little to worry about.
On the other hand, we see a form of censorship day to day in things like Stripe not taking money for certain kinds of companies (I’m sure there are other examples). These are things we know to be essentially true, and they don’t cause a huge problem, we just work around them and while it’s not great, there are enough options to do so and still make a business.
-
-
I liked this article, I thought it was well-written, and I learned a few things.
I was a bit surprised that they didn’t touch on the thing I see that’s most discussed about Elm, which is the state and future of development. Perhaps they thought it was out of scope, or talked about enough elsewhere.
It’s been 15 months since the last Elm release (0.19.1) and the Github pulse for the repo looks like it’s barely beating (I don’t want to read too much into that). Are there Elm developers here? What’s your take on this?
-
There was a thread on that last year, but I do not know how much of that has changed since then:
-
Really glad I read that. Thanks!
-
-
Not an Elm developer (used to use it, slowly removing it from our codebase), but I believe Elm development is done significantly in private, so code is only typically visible upon release. Because of this it does look dead between releases.
I gather the reason for this is something akin to creative control, not wanting to over-promise or set the wrong expectations, things like that. It’s an interesting take on open source culture, and @srid’s comment links to a good rebuttal to it, however I’ve also found hearing it direct from the Elm developers to be a fairly convincing argument at times.
-
I can think of some (but very few) other projects successfully following this mode - sqlite comes to mind. I think it requires a very particular sort of core team.
-
used to use it, slowly removing it from our codebase
Thanks for your comment, would you mind elaborating on why you’re slowly removing it? I’ve always thought it looked like a lovely language, but it’s really unclear to me at the moment whether it’s got any future outside of teams that are already committed (on one side there’s Typescript, on the other Purescript and Mint; the latter seems like more-actively-developed Elm-alike language)
-
-
-
I’ve written my summary of the CTF and my solutions on my blog too for anyone who might be interested.
-
This week I’m starting lectures again, and need to choose a research topic for my masters project. I’m thinking about researching the history of NoSQL databases, and comparing/contrasting current implementations and how they are used to try and clarify the good use cases for each.
(The project isn’t my dissertation, it’s basically a big literature review)
Quicksilver is another open source launcher for macOS. What does this project aim to do differently?
Man, I had no idea Quicksilver was still alive and kicking. I seem to remember it being dead awhile back, which is when I switched to Alfred.
Hmm, I hadn’t heard about this project before. Thanks for the link.
It turns out that there is only one difference between it and spotter - spotter is a cross-platform application which will be released also on windows.
Quicksilver was the app that inspired Alfred, LaunchBar, Gnome-Do, and I think much of the “launcher” market.
It was a fantastic app in its heyday, but unfortunately lost some of it’s quality as macOS progressed and it didn’t quite keep up. It also depended on compiled, typically Objective-C, plugins, which is not how most newer plugin systems are working now, with Node, Python, Lua, etc, being more typical.
I remember using LaunchBar in the Mac OS 7 days (mid-1990s). It well pre-dates Quicksilver.
Apologies, I didn’t know that! Thanks!
Another open source thing like Alfred is Albert, might be worth checking out for further inspiration.
Great app, but looks ugly tbh
I’ve been using Quicksilver for the past 15 years, and I just can’t switch to anything else. I might not be using it’s full potential, but for quickly starting an app or getting me contacts/calculations/files, it’s invaluable.