same ~ I often find myself wishing for the opposite, that we could have clojure.string fns available in the kitchen sink by default. Feels somewhat arbitrary why the re-* family "deserve" inclusion but not something as useful as str/includes? or str/join π
I am going to Brazil in the summer (last two weeks of July and all August ... yes lucky me πΊπΌ). Anyone know any folks over there that is aligned with (eg #C03S1KBA2 and #C0B7Q4XRM1U)? (yes I have asked in #C055AMK5Y but it's quite quiet - they're all on Telegram π€·π»ββοΈ and I am on that forum too. So anyway, I thought I'd expand the search here).
Where in Brazil?
SP, Sao Jose de Rio Preto, Rio, Ilhabela, Belo Horizonte (for a music festival)
Hot take: automatic transitive dependency resolution where you declare 1 dependency and get N others automatically from any number of authors was a mistake
vendor lib ftw?
I don't think that's a solution either. In the background I'm doodling on something where I'm trying to think this through. The only thing I'm convinced of is that the current lack of friction in expanding your transitive dependency tree is unideal
Open to suggestions (and generally want to hear what people think a solution would be)
you know, that is one of the benefits of the vim/neovim plugin ecosystem: you have to manually specify all dependencies so it leads to folks either vendoring or avoiding dependencies in general
(specifically vendoring increases the friction of adding a dependency but it doesn't change the nature of what a dependency is. Copy pasting a folder with source code instead of pulling it over the network or as a compiled artifact doesn't change the fact that you are dependent on an outside party to develop and maintain that software. I agree that part of a solution needs to be adding more friction, but I don't think that's it)
paying? ;)
yeah, let's pay for all the OSS you use. great idea :)
write everything yourself from scratch. Simple.
me /scratches head
It's not not on the list of options
get it from someone else | write it yourself | ??? please say ???
You could make a point for paying for a forge per usage. Multiplex over trusted providers and rev-share model?
@raymcdermott I think there are two related problems. One is that when you get a library from someone else that person is basically always an unfunded volunteer. The other is that it is extremely easy to end up depending on hundreds if not thousands of those unfunded volunteers. In fact it is made very easy to do so
Whether those two problems have the same solution or intersecting solutions I cannot say, but I'm currently approaching it from the perspective of the second one
so is it an issue of funding? You will only trust if the other person is "funded"?
It's one dimension.
When something is not funded directly it's subsidized. Say if you have a "decent tech job" that subsidizes hobbies. "How can this person afford to keep doing this?" And "to what extent can I trust that they are operating in good faith, will align with my interests, ..." Are all related questions
Good luck fixing capitalism. I'm with you βπΌ
Working As Intended (TM)
I've been writing OSS since the early '90s -- sheesh, about 35 years! -- and it had never occurred to me that paying OSS developers should be a thing, until Cognitect/Nubank starting reaching out to offer GitHub sponsorships. I sponsor several projects that I use on a daily basis (although at least one of those should be sponsored by my employer since I use it at work, rather than in my OSS stuff, grumble, grumble).
Nubank has been paying about $250K/year https://www.cognitect.com/blog/2020/12/15/sponsoring-open-source-developers to open source developers. it's a good idea. more companies should do it.
in addition of course to actually paying many people to work full- or part-time as employees on open source
Yeah, I think that's awesome. And Toyokumo. And Clojurists Together. It makes a big difference to those of us on the receiving end -- makes it much easier to justify continuing to work on these projects and to respond to bug and feature requests.
if everyone using open source supported those making it, it would be a different equation for sure.
if Maven Central was pay per download with "royalties" going back to the developers, imagine how that would change the dynamics
ship the compiled artifact and use tree-shaking to reduce code duplication kek