Clojurians Log v2

Morning

Morning!

mogge

Morning!

Good Morning!

Good Morning 😉

Morning!

Morning

Good morning!

morning

morning

Good morning! This weekend I decided to try relay some of the dev experience working with cljs to build mobile apps. The result was a touchup of my exemple project for it and also a screencast where I demo the stuff. I realize it is a big ask, but I would appreciate some feedback on the whole thing. Never done this before and it was surprisingly hard to not stutter my way through it all. Does that make it hard to consume, you think? What could I have left out? What did I miss? Such things. Thanks in advance for any help with this. ❤️ https://www.youtube.com/watch?v=QsUj7HO5xDg

Since few of you probably follow #clj-commons, I’ll seek some advice here. This https://github.com/clj-commons/meta/issues/59 just arrived in “my” mail this morning. Thoughts?

@slipset do you think somewhere else would be a good home? I'm not sure what you are asking?

I guess what I’m asking is “Do you think it would be a good idea for clj-commons to take on these projects?” And then the question is good idea for whom?

So one way to answer that (and anchoring “the for whom”) is if the clojure community would be better or worse off if clj-commons adopted aleph.

And I would hope the answer to that would be “ever so slightly better off”

And to your question @otfrom, I guess the other possible home for aleph would be to stay where it lives now (which seems not to be the best solution, otherwise Zach wouldn’t have approached clj-commons).

clj-commons seems to be the place where useful abandonware has a second life (is that fair?)

so that would seem to be a good place for it

I know that some people have based large chunks of their business on things like manifold

Yeah, I guess that for me the scary bit is the distinction between useful and critical abandonware.

I just commented here: https://github.com/clj-commons/meta/issues/59#issuecomment-735747697 One perceived issue with clj-commons for me is that libs are being brought in, but there isn't really a team of owners that feels responsible for specific libs.

But I guess that sort of comes with the territory

are you seeing the aleph things as more critical and thus higher risk for clj-commons as an org?

I think that might also be a relevant comment for @lee

@otfrom: I’ll digress. https://github.com/clj-commons/meta/issues/18 came up as an issue some time ago. We use saml20-clj at work, and it would’ve been a reasonable project for clj-commons to adopt. But since metabase already had adopted it and was maintaining it, it was natural to let them keep on doing so. Some time later, a security vulnerability was discovered, which is now fixed in the newest versions of saml20-clj thanks to some very impressive work by the people at metabase. What kind’a scares me was if this lib had been adopted by clj-commons and I/we were responsible for fixing the security hole (in a good way).

I think that ties into my comment about ownership. People are usually willing to invest time if they are really using the lib, and are stakeholders so to say. So letting companies adopt libraries seems a better strategy, if possible.

I see the same thing for friend which we also use at work. It’s quite a commitment to take on the maintenance of libs like that, and I guess what I’m really trying to do is to manage expectations.

@borkdude I very much agree upon the ownership thing. I can do life support, but I cannot and will not do active development on critical libs. But I don’t think there is a contradiction between clj-commons and having people/companies owning libs.

True. But when taking in libs into clj-commons, maybe it should be clear from the start who are going to be the responsible people for it. I believe CircleCI is tending after clj-yaml on clj-commons if I'm not mistaking. That's also a great option.

If you feel responsible for everything that goes into clj-commons, maybe something should be fixed. Which is hard, because people who are willing to step up are maybe hard to find.

Yes, Circle is tending after clj-yaml, and that’s perfect. There are other libs which also have dedicated maintainers. And then there are a host of libs which are on life support.

I don’t feel responsible for everything going in there, but I do feel responsible for the expectations.

So if something goes in to clj-commons with no responsible maintainer, I become that maintainer, and the maintenance performed will be at the minimum level, which may or may not be better than current maintenance, but might not be what people expect 🙂

Right.

Having said all this, the stuff you and I did with clj-yaml for babashka (don’t remember if you ended up using clj-yaml in bb or not) would probably not have been possible without clj-commons.

Maybe it's a possible way for other companies, besides Circle, to sponsor the Clojure eco system. Alot developer time for this life support.

yes, it is used in bb!

(well, it would have been possible, but would have taken longer time)

@pez that could work, but you could wonder: a) why would a company throw developer time at lib X if they aren't using it and b) if they are using it, they probably already have their own fork if the lib was unmaintained?

and c) is it a good idea to throw random dev time at library X, if the random developer has no idea what X is?

circle had a fork of clj-yaml, that’s the one that got into clj-commons

I guess c) is the main point here. You don’t just want a random dev to work on aleph, friend, manifold etc. And to a certain extent, I’m just a random dev 🙂

and d) if this is 20% time, the random developer probably has nicer things to do than working on some unmaintained lib ;)

e.g. creating future unmaintained libs

As for d) I’d like to point out that people are different. Some people like greenfield, I like brownfield 🙂

Looking at https://github.com/aleph-io/aleph/issues/450 there should be enough smart people using aleph to help it out…

looking at you there @borkdude 😛

😰

We are still using yada / aleph. But I'm not sure if anyone in my team knows any implementation details of aleph, I certaintly don't

This reminds me of a company I worked in which had on low level C++ developer who developed the main component the rest of our stack was using. Nobody dared to touch it, except him.

And then he started freelancing. But the component was developed for so long, it was kind of done anyway. Seldomly he was hired to fix small things.

And after a few years, everything was based on ElasticSearch anyway instead of his C++ component.

we use and maintain kixi.stats. I do wonder how/if we'll have to keep it going with the way things are in scicloj (I think most things will work)

I suppose Apache/Linux Foundation/FSF try to solve this problem

there are going to be some issues around copyright assignment and licensing potentially

I think the goal of clj-commons is similar to that of such foundations. The main issue seems to be: where do you find the people willing to be the maintainers.

I suppose go on a recruitment drive. Not sure how the other orgs go it

debian is going to be another example

I will admit to not knowing entirely how it works here

A bit off topic: asciidoc. Surprising result: I put some effort into making http://book.babashka.org seem "nicer" using a framework, but so far people like the simpler approach. https://twitter.com/borkdude/status/1333371433448329217

I was actually thinking about kixi.stats in all this. That’s another lib that I’d be very scared of maintaining 🙂

Maybe @rahul080327 has some ideas about this too, he seems to be active within Debian circles

or should I say “give life support to”

as it isn't too big I like the all in one page

it might become bigger

If someone comes with a PR which claims to fix the normal distribution fn, I’d be lost.

@slipset I think as long as we keep going and keep selling witan.send and witan.cic that we'll keep supporting kixi.stats and paying people to do that

we being Mastodon C

@otfrom I’d hope (and expect) that, it was more of a hypothetical example of things I’m not competent on handling.

Is there any precedent of open source libs going out of fashion but unexpectedly being revived years later and becoming popular again?

kixi.stats is the heart of both of those models and those models are 90% of our business

For reasons I was playing with kixi.stats this weekend. and that got me thinking.

we've not really done too much work to try to create a community around kixi.stats similar to what is going on with scicloj. Partly I'm not sure how many people would be keen on it

Ie, dist/cdf is a function I was using, but have no understanding of, neither the implementation nor the stats behind it.

but creating a community around it is a way of keeping things going (which is something I learned while "recruiting organisers" from those who complained at London Clojurian meetings)

haha

(I am so so so happy that community has a better life after me than it ever did with me)

@slipset hmm.. I wonder if some kind of stats book around the things in kixi.stats would be the way to go

it would need some stuff on the implementation, but then a fair bit on the maths in the docs as well

I think what's going on with rewrite-clj now is pretty great as well. First there was rewrite-clj, and rewrite-cljs. Both are now unmaintained. But @lee is stepping up to combine these into rewrite-cljc which will be hosted under clj-commons. This is a lib I'm a fan of and willing to maintain together with lread.

Yes, but the point was if someone called Bruce approached clj-commons and asked them to maintain kixi.stats, I’d be about as scared (much for the same reasons) as for maintaining aleph.

And if that happened, and I said yes, and then someone came along with a PR that would “fix” the dist/cdf fn, I’d be in way above my head.

yeah, scicloj would be a better org for that than clj-commons

I wouldn't trust anyone named Bruce if he came bearing source code he didn't want to maintain any more

not that I know any Bruces

Also, scicloj is now building something around using R libs from Clojure? that will make kixi stats obsolete probably :P

lol

clojisr?

I think so?

that is the bridge to R

yeah. kixi.stats is hitting a slightly different sweet spot

If you are doing something in R and would like it to be a lot faster then I'd hope it was in kixi.stats

kixi is faster than R?

that is the overall idea (faster, more robust)

cool

since it's "just" math, I could see maintaining this would be easier than say Aleph, of which there are no off the shelves theory books for

it isn't going to cover all of CRAN, but then I'm not sure anything really will

well, surely all the stuff in Aleph should have TLA+ proofs. 😉

(the R stuff should be a lot faster with clojisr and/or using Arrow to move data back and forth)

I’ll ping Hillel Wayne then…

glad to see my supposedly obscure jokes landing 🙂

I saw it!!!

I reserve the right to delete my really bad jokes. This is why I'm not safe to be on IRC ;)

It’s too bad when prolific authors of open source libraries suddenly abandon their stuff. How do you replace the singular vision of a super talented individual? I just saw Karsten Schmidt’s umbrella project appear on the frontpage of Hacker News and it reminded me how he stopped development of https://github.com/thi-ng/geom after it reached 1.0 and has focused all of his efforts on TypeScript since then. Not sure if Clojure suffers more from this than other programming language communities, but it’s sad to see in any case. Even if it’s perfectly fine software, knowing that it’s abandonware is a red flag.

I do wonder about adopting thi-ng/geom

partly b/c I'd like a pure clojure svg charting library

but that means I only really want a part of it

I had the same problem with Incanter (far to big for me to take on)

@simongray sad, but expected, I guess. People move on. Problem is that we rely on that work, but we fail to put in place an infrastructure to support that work when people move on.

I don’t think clj-commons should take on the really heavyweights of the Clojure library ecosystem. Perhaps only just as temporary stewards and guardians of the clojars password until some qualified maintainer stepped up and was willing to continue development.

Temporary can take a long time

Well yes but now the “ownership” of the library is within a trusted group that can pass the baton, and can put out an announcement that says “this project is on ice until someone steps up”. Of course Zach could also say that but perhaps it’s a bigger signal to do it in a “commons” group?

yeah, that makes sense

The nightmare scenario is if someone shows up and makes a malicious fork of aleph somehow claiming to be the continuer, and tricks Zach or clj-commons to give them the clojars password…

I suppose then the problem is that clj-commons becomes the certifier of the new maintainers, which has its own risks but is probably better than the scenario you've laid out

this is the nightmare scenario

https://snyk.io/blog/malicious-code-found-in-npm-package-event-stream/

if the project is in life support personally I would just archive it, people are free to fork it and continue to maintain it under another group-id, it's quite effortless. Then one fork might emerge as the successor if there's enough momentum

@mpenet in theory, yes, but then it becomes a hassle when you want to use a lib. Who’s fork is the least malicious one. Or the best maintained. And why spread the maintenance burden on each user of the lib?

Seems to me that the commons role is to act as a handover point.

yeah, but what could also happen is that the aleph-io allows interim devs from clj-together to manage the repos for a while (life support), waiting for other people / companies to come along

if there's already an org, I don't see the need of transferring repos

I use docjure for my excel bashing needs, does anyone have a good library for talking to google drive or google sheets?

Commons acts as a long term solution. You know that if the current company loses interest, then commons will pass it on.

Good night https://photos.app.goo.gl/wyLatxLZWiacdRPv6