search

sjbarag / brs

An interpreter for the BrightScript language that runs on non-Roku platforms.
MIT License
113 stars 43 forks source link

Consider transferring project to RokuCommunity #681

Closed TwitchBronBron closed 1 year ago

TwitchBronBron commented 1 year ago

Is this project still being maintained? The last commit and release was in September 2021, so it appears that nobody is actively maintaining this project anymore.

I still see a lot of value in this project living on and being actively maintained. With the new brsfiddle.net site, potential integration of a brs repl in the vscode extension, and even for its original unit testing purposes, there's a lot of future potential. I'd hate to see the project die.

I am the founder of the RokuCommunity organization. If this project is no longer being maintained, we at RokuCommunity would be happy to adopt the project to make sure it is more actively maintained.

@sjbarag if the project is indeed no longer being maintained, are you open to this idea?

For the sake of the community and also just to be a good citizen of open source, I'd love to see both the GitHub project and the npm package get transferred to RokuCommunity. This has the following benefits:

I think our track record speaks for itself. We've adopted other abandoned roku related projects (roku-promise, roku-requests), and our vscode extension and community tools have been very popular in the Roku community since we were founded in 2019. I hope you'll consider this request.

sjbarag commented 1 year ago

Heya — the project is not being maintained at this point, and hasn't been since probably mid 2021. Let me take some time to think about the next steps here.

sjbarag commented 1 year ago

I appreciate the offer, thanks for laying out a thoughtful message! After a bunch of thought though, I'm not willing to transfer this repo. In fact, I'm going to archive it in a few weeks, but I'm happy to link to a successor in the README if you'd like. There's a bunch of reasons laid out below, but that's the short version.

History & Context

This repo was originally and has always been a side project of mine, created because I wanted some tests for some array utility functions to run in CI. But also because it was fun! I learned a lot, and eventually convinced my bosses at @Hulu to allow me and some coworkers to contribute during work hours. We got a ton of benefit out of it, and that led to roca an eslint plugin. Even with those corporate contributions, ownership of the project remained with me — they were modeled like any other open-source contribution.

Throughout 2021, nearly all of the folks at Hulu who contributed to those projects either moved away from the Roku space or left the company entirely (and also no longer work in the Roku space). I'm part of that latter group, having left the company in autumn 2021 with no remaining developer interaction with BrightScript.

Since then, activity in this repo has dropped off to nearly zero:

The project didn't die just because I stopped contributing to it. It died because no one has contributed to it, RokuCommunity included. That's not inherently bad: devs lose interest, change areas of focus, leave software development entirely, or just lose the free time to contribute. Life happens, and I don't fault anyone for not sending pull requests to my silly little project!

Why I'm Not…

That said, I don't think transferring things is the best path forward for me, RokuCommunity, or the users of this package.

Transferring This Repo to a Different Org

With the most recent pull request filed 501 days ago, there hasn't been any continued development on this project. The current ownership doesn't stop anyone from opening pull requests — forks and PRs are still enabled — so it's pretty clear that no one's been willing to contribute to the project. Changing ownership is not a prerequisite for restoring activity to this project, nor does it guarantee that activity will return after the change.

Selfishly, this is a very significant piece of work that I'm very proud of! If it's going to continue to be dead, I'd rather it be dead in my name (and archived).

Granting Additional Ownership to This Repo

Giving someone commit access to a repo owned by my account requires a significant amount of trust. You and I have worked together a little bit in the past, but not nearly enough where I'd be comfortable granting you commit access, let alone owner.

Transferring the NPM Package

Concerns about renewed activity aside (see above), publishing the same NPM package from a different repo doesn't seem to be particularly beneficial. The cost of switching dependencies appears to be pretty low.

From a GitHub search, excluding forks of this repo, there's eight public packages that directly depend on this one:

Repo Last Commit
sjbarag/brs (this) 2021-09-22
willowtreeapps/vscode-ide-brightscript 2018-10-28
hulu/roca 2021-10-27
haystacknews/sg-flex 2022-09-11
kaltura/kaltura-player-roku 2021-07-27
hulu/eslint-brightscript 2021-06-17
triwav/roku-jsdocs-plugin 2020-07-19
slheavner/rooibos-cli 2021-08-13
georgejcook/rooibos-cli 2020-07-22

Of those, just six have a history outside of me/Hulu. Of those six, only one (kaltura/kaltura-player-roku) has seen a commit to its HEAD in the past year.

It's an even simpler story with the dependents list on npmjs.com: Of the three projects outside the @hulu scope, only rooibos-cli isn't marked "deprecated". It was last published in June 2020.

There are of course private projects, projects not on github, and a whole host of other reasons why dependencies may not show up here, but I can't comment on them. Given what's visible to me, it seems that only a very small handful of projects would be impacted by an NPM package change.

What I Recommend

A fork of this repo owned by @RokuCommunity, plus an NPM scope of @rokucommunity seems to be the best bet for your users. It allows all RokuCommunity projects to be collected in a single logical group (and listed next to each other in package.json!), which is a net-positive for the RokuCommunity initiative as a whole. It lets RokuCommunity take complete ownership over the publishing flow, and means I can't accidentally break publishing by deactivating an NPM access token.

Most importantly, a fork + new project signals to consumers that it's a different project. RokuCommunity gets the freedom to change directions wildly without worrying so much about alienating users, and to make breaking changes on your own terms. Any project using @rokucommunity/brs is guaranteed to be actively maintained — at least as-of the initial publish — which gives RokuCommunity a stronger signal of who's even using this thing.

Aside: Perception

I recognize that this looks a bit like me "taking my ball and going home", but the reality is that I'm not taking away anything that's already present. The code for this project will continue to exist and be MIT licensed, and the NPM package will remain available for any project that needs it in its current state.

strattonbrazil commented 1 year ago

Well said, and a thorough thought process.

On Sat, Apr 15, 2023, 4:35 PM Sean Barag @.***> wrote:

I appreciate the offer, thanks for laying out a thoughtful message! After a bunch of thought though, I'm not willing to transfer this repo. In fact, I'm going to archive it in a few weeks, but I'm happy to link to a successor in the README if you'd like. There's a bunch of reasons laid out below, but that's the short version. History & Context

This repo was originally and has always been a side project of mine, created because I wanted some tests for some array utility functions to run in CI. But also because it was fun! I learned a lot, and eventually convinced my bosses at @hulu https://github.com/hulu to allow me and some coworkers to contribute during work hours. We got a ton of benefit out of it, and that led to roca https://github.com/hulu/roca an eslint plugin https://github.com/hulu/eslint-brightscript. Even with those corporate contributions, ownership of the project remained with me — they were modeled like any other open-source contribution.

Throughout 2021, nearly all of the folks at Hulu who contributed to those projects either moved away from the Roku space or left the company entirely (and also no longer work in the Roku space). I'm part of that latter group, having left the company in autumn 2021 with no remaining developer interaction with BrightScript.

Since then, activity in this repo has dropped off to nearly zero:

The project didn't die just because I stopped contributing to it. It died because no one has contributed to it, RokuCommunity included. That's not inherently bad: devs lose interest, change areas of focus, leave software development entirely, or just lose the free time to contribute. Life happens, and I don't fault anyone for not sending pull requests to my silly little project! Why I'm Not…

That said, I don't think transferring things is the best path forward for me, RokuCommunity, or the users of this package. Transferring This Repo to a Different Org

With the most recent pull request filed 501 days ago, there hasn't been any continued development on this project. The current ownership doesn't stop anyone from opening pull requests — forks and PRs are still enabled — so it's pretty clear that no one's been willing to contribute to the project. Changing ownership is not a prerequisite for restoring activity to this project, nor does it guarantee that activity will return after the change.

Selfishly, this is a very significant piece of work that I'm very proud of! If it's going to continue to be dead, I'd rather it be dead in my name (and archived). Granting Additional Ownership to This Repo

Giving someone commit access to a repo owned by my account requires a significant amount of trust. You and I have worked together a little bit in the past, but not nearly enough where I'd be comfortable granting you commit access, let alone owner. Transferring the NPM Package

Concerns about renewed activity aside (see above), publishing the same NPM package from a different repo doesn't seem to be particularly beneficial. The cost of switching dependencies appears to be pretty low.

From a GitHub search https://github.com/search?type=code&auto_enroll=true&q=path%3A**%2Fpackage.json+%5C%22brs%5C%22++NOT+is%3Aarchived&p=3, excluding forks of this repo, there's eight public packages that directly depend on this one:

| Repo | Last Commit | | —- | —-- | | sjbarag/brs (this) https://github.com/sjbarag/brs | 2021-09-22 | | willowtreeapps/vscode-ide-brightscript https://github.com/willowtreeapps/vscode-ide-brightscript | 2018-10-28 | | hulu/roca https://github.com/hulu/roca | 2021-10-27 | | haystacknews/sg-flex https://github.com/haystacknews/sg-flex | 2022-09-11 | | kaltura/kaltura-player-roku https://github.com/kaltura/kaltura-player-roku | 2021-07-27 | | hulu/eslint-brightscript https://github.com/hulu/eslint-brightscript | 2021-06-17 | | triwav/roku-jsdocs-plugin https://github.com/triwav/roku-jsdocs-plugin | 2020-07-19 | | slheavner/rooibos-cli https://github.com/slheavner/rooibos-cli | 2021-08-13 | | georgejcook/rooibos-cli https://github.com/georgejecook/rooibos-cli | 2020-07-22 |

Of those, just six have a history outside of me/Hulu. Of those six, only one (kaltura/kaltura-player-roku) has seen a commit to its HEAD in the past year.

It's an even simpler story with the dependents list on npmjs.com https://www.npmjs.com/package/brs?activeTab=dependents: Of the three projects outside the @hulu scope, only rooibos-cli https://www.npmjs.com/package/rooibos-cli isn't marked "deprecated". It was last published in June 2020.

There are of course private projects, projects not on github, and a whole host of other reasons why dependencies may not show up here, but I can't comment on them. Given what's visible to me, it seems that only a very small handful of projects would be impacted by an NPM package change. What I Recommend

A fork of this repo owned by @rokucommunity https://github.com/rokucommunity, plus an NPM scope of @rokucommunity seems to be the best bet for your users. It allows all RokuCommunity projects to be collected in a single logical group (and listed next to each other in package.json!), which is a net-positive for the RokuCommunity initiative as a whole. It lets RokuCommunity take complete ownership over the publishing flow, and means I can't accidentally break publishing by deactivating an NPM access token.

Most importantly, a fork + new project signals to consumers that it's a different project. RokuCommunity gets the freedom to change directions wildly without worrying so much about alienating users, and to make breaking changes on your own terms. Any project using @rokucommunity/brs is guaranteed to be actively maintained — at least as-of the initial publish — which gives RokuCommunity a stronger signal of who's even using this thing. Aside: Perception

I recognize that this looks a bit like me "taking my ball and going home" https://idioms.thefreedictionary.com/take+your+ball+and+go+home, but the reality is that I'm not taking away anything that's already present. The code for this project will continue to exist and be MIT licensed, and the NPM package will remain available for any project that needs it in its current state.

— Reply to this email directly, view it on GitHub https://github.com/sjbarag/brs/issues/681#issuecomment-1510000798, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGAAJ5IN4N3XQP2CS66NXDXBMWENANCNFSM6AAAAAAWJNACZU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

lvcabral commented 1 year ago

We understand @sjbarag and thanks for your work, I learned a lot collaborating with your project and later creating my fork for the emulator. We will take good care of your child.

TwitchBronBron commented 1 year ago

@sjbarag fair enough. Thank you for at least considering it, and for providing such a detailed justification for your decision.

Thanks for such an awesome tool. :)