Address the "bus factor" of Buckets

[iffy]

No description provided.

[joneshf]

Thanks for making this issue! It makes me feel like you listen to us, and that the survey was useful to take.

Any preliminary thoughts on how you might deal with this concern?

[iffy]

I think this is actually 2 issues:

1. My capacity as a solo developer (i.e. throughput, bandwidth)
2. What would happen if the bus got me (or some other life change that prevented me from continuing work on Buckets)

I've mostly given thought to the latter and plan to prepare a document for that. But I think I ought to give more thought to the former, too. Regarding the latter, my preference is to either hand it off to friends/family (who are also programmers) or open source it.

[Limezy]

Very interesting subject. However, why did you label it as a "bug" ?

[iffy]

@Limezy Mostly because bugs have a red label (and I have lists where bugs feature more prominently) so they're harder to forget :) But you're right that it probably isn't technically something that prevents people from doing their budget.

[iffy]

This last week, I made one huge improvement to the bus factor for Buckets. For the last 3-ish years there's been only one computer on earth capable of creating new releases of Buckets 😬 But now it is built automatically via a Continuous Integration (CI) service whenever code is pushed there. This is a huge relief and a step toward increasing the bus factor of Buckets!

[ctheune]

The bus factor could also be addressed with some kind of canary + escrow system to release as open source. I'm not sure whether there are good/cost efficient services/solutions that provide this, though.

The bandwidth factor is interesting because just making it open source means that you'd add the burden of coordinating other people versus it being a personal project that you can use to enjoy (I hope) and have fun with and grow. Looking at some of the issues makes it a project that I could imagine contributing a bit of time to (which isn't much at the moment due to kids and a lot of other stuff already on my table). Nevertheless, I'm impressed that you've been developing buckets for quite a while already and am happy to pay for it to provide at least some revenue to you.

I currently don't know about a model that has been proven to work reliably where you'd be able to add more contributors and just keep the revenue. I'd personally be happy to contribute and just be a light help, but I don't think it's possible to grow a community of developers from that point. And I do have my own pet projects where I completely would not want to add the burden of growing a developer community instead of just spending quality time with my own code.

Thanks for considering the issue so openly though. I'd be happy to chat about it if you want to do some mental sparring at any point in time.

[iffy]

@ctheune You've described many of my own thoughts very accurately. I enjoy programming more than I enjoy managing (having tried both). I'm not opposed to eventually making Buckets into a project I manage more than I program but at this point, my preference is definitely to program :)

[iffy]

Got to this from a HN link today: https://en.wikipedia.org/wiki/Source_code_escrow related to ctheune's prior comment.
That there's no pricing makes me think this is too expensive a company to use: https://softwareresilience.nccgroup.com/software-resilience-services/software-escrow-agreements/ (And it gave me a good chuckle imagining a company going bankrupt because of an expensive escrow bill 😄 )

[Limezy]

I've already used a software escrow mechanism at work and it wasn't so expensive (but not only a few bucks, though).
@iffy Couldn't github act as a free escrow ? I guess a few lines of code with github API could make somethink like : if no commit activity for more than 6 month ==> pass the repository as public ?

[iffy]

if no commit activity for more than 6 month ==> pass the repository as public ?

I'd rather have a human decide to release it so there's no chance a software bug accidentally publishes it. I've been known to unintentionally produce bugs in the software I write 😉

[joneshf]

On the more morbid side of the "bus factor" phrase–i.e. death–GitHub does allow you to designate a successor.

On the less morbid side of the phrase–e.g. losing interest, not having time, etc.–maybe it's enough to make that decision when those life events come up?

[pippil]

I have to say I hope you do not lose interest, @iffy - the philosophy you have breathed into Buckets is a big part of what makes it a special application. It is my sincere wish that should there ever be a successor, the philosophy behind Buckets is respected and maintained.