Live data from Hacker News

Fork Freshness: Project lifespans in the Ruby ecosystem

gilesbowkett.com

31–38 of 38 posts

Re: Fork Freshness: Project lifespans in the Ruby ecosystem

#31

Fork Freshness is poking at an important problem. If the author of an open source project stops responding, then there is usually no obvious way for the project's community to reorganize or recognize a new leader or a replacement for the project. I agree with other commenters; I really don't want to talk about my dependencies on twitter to this bot.

author here! maybe I'll cave and just set up a regular UI. email might work also.

not entirely on-topic, but you're picking at another tendril of what https://adoptoposs.org is picking at

Re: Fork Freshness: Project lifespans in the Ruby ecosystem

#32
post #2

Is there a reason this requires a Twitter account? Seems like something I'd like to use but I don't have Twitter.

The author says it's too slow and works better as an asynchronous request. They also write something about rails' "User" object being unwieldy, whatever that is. That still doesn't explain the Twitter dependency. It could just be an attempt to get popular and share the tool at the same time.

I sympathise with this a lot. It's tempting to say "oh just use ActiveJob, and a CAPTCHA to stop bots, and Devise for auth, and MailChimp to let users know it's completed, and build a UI for submitting new jobs, and also for viewing pending and completed jobs", but all those little things add up.

Re: Fork Freshness: Project lifespans in the Ruby ecosystem

#33
post #32

Earlier quoted context omitted.

The author says it's too slow and works better as an asynchronous request. They also write something about rails' "User" object being unwieldy, whatever that is. That still doesn't explain the Twitter dependency. It could just be an attempt to get popular and share the tool at the same time.

I sympathise with this a lot. It's tempting to say "oh just use ActiveJob, and a CAPTCHA to stop bots, and Devise for auth, and MailChimp to let users know it's completed, and build a UI for submitting new jobs, and also for viewing pending and completed jobs", but all those little things add up.

Solve the bot problem when you get too popular, don't preemptively make it harder for people to try out your site.

Re: Fork Freshness: Project lifespans in the Ruby ecosystem

#34
post #27

Earlier quoted context omitted.

> I wrote that up here, in a fairly gigantic blog post: That blog post is the same link for this thread. > without creating a User model A User model isn't necessary if you don't require login to use your tool.

> My theory now is that whichever ActiveRecord model is closest to the UI will grow huge as it comes to incorporate a comprehensive catalog of user interactions. It's an interesting question, but it's also a topic for another time. User preferences, settings, interaction history, whatever can be stored in different models. The User model can be slim.

Good to know. It seemed odd to include details about the framework. The tool could've been written in Django, Angular, React, etc.

Re: Fork Freshness: Project lifespans in the Ruby ecosystem

#35

Fork Freshness is poking at an important problem. If the author of an open source project stops responding, then there is usually no obvious way for the project's community to reorganize or recognize a new leader or a replacement for the project. I agree with other commenters; I really don't want to talk about my dependencies on twitter to this bot.

author here! maybe I'll cave and just set up a regular UI. email might work also.

[deleted]

Re: Fork Freshness: Project lifespans in the Ruby ecosystem

#36

Fork Freshness is poking at an important problem. If the author of an open source project stops responding, then there is usually no obvious way for the project's community to reorganize or recognize a new leader or a replacement for the project. I agree with other commenters; I really don't want to talk about my dependencies on twitter to this bot.

This might also be a great way for the original creator to identify that people still find their software useful. It might help in handing off the project to an active community.

yeah, that's an explicit goal: to surface the implicit/nascent open source communities that are already coalescing around projects.

if a bunch of people all agree that it's worthwhile to keep a particular project alive, and they're doing the work to make it happen, then they have something in common, and it should be easy for them to meet each other.

Re: Fork Freshness: Project lifespans in the Ruby ecosystem

#37
post #16

Earlier quoted context omitted.

Presumably the poster means "grunt"

Swipe typos have made detection more complex.

I think it was “fork,” which is very close to “girl” in swipe.

You’re right it was likely a swipe typo. I’ve transitioned to swipe typing about 70% of the time. Hadn’t done it at all until a few months ago.

Not sure how I waited so long to start using it, or if I’m more productive typing using it now.

Re: Fork Freshness: Project lifespans in the Ruby ecosystem

#38
post #37

Earlier quoted context omitted.

Swipe typos have made detection more complex.

I think it was “fork,” which is very close to “girl” in swipe. You’re right it was likely a swipe typo. I’ve transitioned to swipe typing about 70% of the time. Hadn’t done it at all until a few months ago. Not sure how I waited so long to start using it, or if I’m more productive typing using it now.

I had a feeling it was, but as swipe typos go, it's... shall we say ducking hilarious? :)
Post reply on HN