Will these projects be supported or maintained?

[solvingj]

@mh-cbon Over the past month, I've opened several github issues and PR's on several of the projects related to this one. I've seen other people have done so also. I've only seen one or two of these items be addressed since May.

Please indicate if you intend to support these projects long-term, or if you are likely to be too busy and we should seek other solutions.

[mh-cbon]

Please indicate if you intend to support these projects long-term, or if you are likely to be too busy and we should seek other solutions.

Let me try to put it differently, by putting your eggs into one and only one bag, you put yourself in a tricky situation.
Could it be a company or an individual (currently its an individual), its their multiplicity that will give you the kind of insurance you are looking for.

As long as there will be active contributors, those projects will be maintained, were there that much of contributors so far, nop (this is all public data), thus, honestly speaking, did you put yourself at risk, given your message, i d say yes.
On the other hand, if everybody is looking at each other to see if they going to move to decide of their own move, nothing will happen.

To my peculiar situation, none of this work is backed by money. I let you make your own conclusion of that.

Being talking about those questions, i don t pretend this is the final solution to any of the problem addressed, i hope and wish other variations will come up, could it be update and maintenance of this project or something totally new, they are both variations.

Long story (very) short, up to you.

[solvingj]

Thank you for the response. It's helpful to know that these are all oss-projects from one person and not backed by a company. Would you ever consider taking co-maintainers (if qualified and after a period of contributions) if the project became more popular?

As for risk, I've only taken small risk, I invested quite a bit of my time to learn all the tools, which is fine. The tools have significant value in their current state. I posted this question to help me decide whether or not to promote the library to the community.

In this case, I will continue to use the tools for my team(s) and probably submit PR's over time. They were very mature when you released them which means the only risk is not getting minor bugs fixed or feature requests over time. The worst-case scenario is having to release our won binaries from our fork, which we're already doing. It is much less desirable than having one or more maintainers actively supporting (but better than using other tools).

In closing, I want to tell you that I think you may underestimate how broadly useful, powerful, and brilliant your toolset is. There's nothing else that does what they do, and has the same characteristics:
-OSS
-Cross platform native binary
-Truly modular
-Consistent and well-formed APIs for packaging across platforms

Thanks again for the contributions and response.

[mh-cbon]

Would you ever consider taking co-maintainers (if qualified and after a period of contributions) if the project became more popular?

yes definitely. imho, popularity is not good criterion to me, its indicator that something worth looking at.

In closing, I want to tell you that I think you may underestimate how broadly useful, powerful, and brilliant your toolset is.

I can tell you are hitting a point, "underestimate" is the word i here the most often about myself when people come to tell their feelings about my being.

About the project status, imho, i think it is still a long way to go to make it really good, so far it has been made to serve one purpose, easy package bumping for go project, and i believe its ok (they are a lot to criticize, but fact is it makes the job). But package bumping is only one operation of a larger process, project versions management, which definitely needs work.

In general, your contributions are welcome and appreciated.