Consider transferring project to RokuCommunity

[TwitchBronBron]

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:

• the existing pull request history and issues are maintained.
• there is no need for a separate npm package name. brs is the perfect name, and I'd hate to have to start using @rokucommunity/brs if brs is going to be forever killed. Seems like a waste.
• There is continuity in the project (i.e. devs don't need to run around swapping their npm dependencies, finding the "wrong" version online and needing to read "this project is dead, use some other one instead", etc...)

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]

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]

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:

• One pull request (Implement clone #672) was opened by a human, on November 30, 2021. ([DON'T MERGE] Empty commit to trigger new builds #673 was a "DON'T MERGE" PR to trigger CI in support of Implement clone #672, so let's ignore it)
• Three issues (besides this one) have been opened:
  • Script tag without src cause parser error #671 (opened Oct 11, 2021) and Invalid check when on the left side does not work (boxing issue) #680 (opened Feb 7, 2023) are bug reports
  • PinPad is not implemented #674 (opened Feb 11, 2022) is a missing component

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]

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: - One pull request (#672 <#672>) was opened by a human, on November 30, 2021. (#673 <#673> was a "DON'T MERGE" PR to trigger CI in support of #672 <#672>, so let's ignore it) - Three issues (besides this one) have been opened: - #671 <#671> (opened Oct 11, 2021) and #680 <#680> (opened Feb 7, 2023) are bug reports - #674 <#674> (opened Feb 11, 2022) is a missing component 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 <#681 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGAAJ5IN4N3XQP2CS66NXDXBMWENANCNFSM6AAAAAAWJNACZU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[lvcabral]

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]

@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. :)

[AlexDev404]

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.

That's a lot of AI, bs, and twisted logic just to satisfy your ego. There is no "trust" when it comes to open source, as forking is essentially the same as transferring ownership in this case since all of the dependencies you listed have:

1. Either become obsolete or nonexistent, or
2. Have switched to this new dependency fork

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.

And get a hint. Because you deliberately ignoring pull requests and issues is what caused the halt of your project. It wasn't that nobody wanted to contribute--but rather you ignoring the project on a whole. So you then turning around and saying that "it's pretty clear that no one's been willing to contribute to the project" is completely false and unjustified.

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).

And I'm pretty sure that nobody who even looks at this repository sees any "great image" that you were hoping for them to see (I most certainly did not) but rather sees a selfish and self-centered person who could've been the death of a platform's support--and was very, very casually fine with it too. Along with someone who failed to do their duty in supporting a community who depended on them in a time of need and someone who literally doesn't give half a damn (as you haven't even made an effort in the past two years to follow up with what you said you would do to the people in this issue).

Everyone understands that others "have life" but that doesn't give you an excuse to completely abandon your repository which others so clearly depended on and even made attempts to contribute and make pull requests to.

Many open source contributors/maintainers/authors have the right to say the same but in the end still care and push themselves to do what's right for the community and see the value of their work. And because of that things have improved over the years. Because what value does the work have to just hang it up on the wall like a trophy/keep it to yourself and watch as others suffer because of it as it collects dust?

Could you not see that you have lost relevance because of your attitude towards the people who were only trying to help? Why could you not have just done the same or at least see that?