Sentiment on Hive is at an all-time low right now. Liquidity is a massive problem. There are serious alarm bells going off that make this feel way more dire than the 2022 bear market. In that kind of environment, the community should be doing everything it can to encourage people to get involved (beyond farming weighted upvotes for HIVE), even if it means someone is diving into the deep end of the Hive codebase and doesn't follow the exact submission process on the first try.
On the TUI wallet thing, that's no different than the fact Hive has like 20 alternative web UI clients being maintained by solo devs and teams outside of the main hive.blog frontend. Nobody tells those developers to stop building because something similar already exists. Overlap and experimentation is healthy, especially for a chain that could use all the builder energy it can get right now.
From my perspective, the Hive blockchain has become quite stagnant. If we're not getting SMTs, we need something. Right now the only thing we have is third-party layer 2 solutions like Hive Engine, which work, but they're centralised and error prone. They're bandaids, not solutions. The roadmap lists "smart contract design prototyping" under Q1 2026, but we're well into Q1 now and the last official blog post from the Hive team was two months ago. There is an issue that is almost 2 years old, looks like no movement has been made (or the issue is stale): https://gitlab.syncad.com/hive/haf/-/issues/214
Not to criticise people putting in the hard work, but from an outsider perspective the priorities seem a little strange. A significant amount of effort is going into running hived on ARM-based mobile phones. To what end? Who is the user for that? Meanwhile the chain has no native token standard beyond HIVE and HBD, no smart contracts, and the L2 infrastructure everyone depends on is run by third parties with single points of failure. Mobile nodes are an interesting technical achievement, but they don't solve the problems that are actually driving people away from Hive right now.
And going back to SMTs if they're not coming, an official layer-2 solution like it appears is planned is better than relying on community layer-2 solutions and it should come BEFORE making it possible to run Hive on arm-based mobile devices and anything else that appears to be higher priority. Maybe I'm just completely out of the loop why they're not a higher priority, but they really should be.
And let's talk about the DHF, we should probably apply that same energy of how we gatekeep contributions to how we spend community funds.
The DHF has had well-documented issues with accountability and transparency. Look at the disgrace that is Valueplan, and community members have been raising red flags about opaque spending, questionable allocations, and a general lack of measurable outcomes for ages now. We've had people funded to buy first aid kits at prices that would make a hospital blush, rally car sponsorships with unclear ROI, and communities with 80 active users sitting on six figures in funding (amongst the other scams and grandiose grifting schemes).
It's ironic that there isn't more concern with the DHF has been haemorrhaging funds with minimal oversight. We've arguably rewarded the wrong people in this community. The people who know how to play the funding game get paid, while the people who actually want to write code and build things seem to get pushed away. For years Hive has rewarded grifters instead of more builders. It has rewarded pie in the sky ideas that didn't even have a detailed roadmap or concrete plan. We just said, "Yep, here's some DHF funding, good luck and pretty promise to keep us update and keep working on it!"
We've taken a detour here, but the point is the focus is in the wrong areas of this place and we really aren't in a position where we can be high and mighty about the level of contributions when things are a damn mess. It's not even evident to a newcomer where they would begin, what the process is. Because it's not documented in a clear and obvious place. And if it is written down somewhere, it's hidden or in multiple places or out of date. For example, I assumed that there was a process in place to handle contributions to the mirrored repository (because Git allows you to do stuff like that). Being on Github (which is where the majority of devs manage Git repos) makes it more accessible to developers who already use it and saves the hassle of having to manage credentials for another platform.
There's also a broader visibility problem here. Where is the development happening? What's actually being worked on right now? When will it be done? These are basic questions that any contributor, existing or potential, should be able to answer by looking at the project. But they can't. It's easy to say look at Gitlab or wherever, but the repository shows active work, it doesn't show what the priorities are, the cost.
The roadmap is vague and outdated, communication from the core team is infrequent, and unless you're already embedded in the right Mattermost channels, follow the right accounts or Discord channels, you're essentially flying blind. Maybe when HIVE was at its all-time high these things were easy to sweep under the rug. Price was up, everyone was happy, nobody asked hard questions. But we're not in that world anymore.
The priorities need to be addressed, and we should start by welcoming everyone with open arms to build and contribute on Hive. Even if those contributions don't result in a finalised, merged outcome, that effort still has value. It would be a bit rich to turn away willing developers when we've been happily funding people through the DHF who delivered far less, except those people actually got compensated for it.
Right now we should be encouraging everyone to get out of their comfort zones and contribute. Even if it isn't 100% aligned with the current direction, everything starts with getting involved. A wrong branch or a PR to the mirror instead of an MR to GitLab are trivial things to fix. The hard part is actually getting people to care enough to try, especially when they're willing to do it for free.
It can take months for even the most experienced developers to get accustomed to a new codebase and understand how everything works. And I don't exactly see a large number of people who seem willing to touch the Hive codebase nor C++ devs in this community. I primarily see Node.js and Python developers, which is fine, but we should be more supportive and encouraging.
I guarantee not everything will be great, but even if a fraction of what someone does helps, that's a good thing. It's not like people wanting to contribute are being paid by blocktrades. Or maybe someone submits something and it makes others go, "Hey, that's a good idea. I can see where they're going, lets collaborate on making this work or exploring the direction we should be going"
This might be seen as reactive criticism, but I love Hive. I still see the potential, but we don't have the luxury of being pretentious and pushing people away when we've fallen so far and now crypto is entering what appears to be another bear market (which is battering the fuck outta altcoins). The sign out the front of Hive should say, "WE WELCOME ALL CONTRIBUTIONS IN ALL FORMS"
Many fair points here.
One thing I should add: with coding LLMs being so accessible, it's become very cheap to submit changes and very expensive to review them properly. Not all AI assisted contributions are like that, but the problem is real: big changesets, lots of confident-looking code, and the burden gets pushed onto a small group of people actually capable of professional review.
My main job as a witness and a core dev is security and reliability of the network. In consensus code QA is everything. Small bug can result in a catastrophe that's not trivial to fix.
So yes, contributions are welcome. But welcome doesn't automatically mean helpful in the short term, and it definitely doesn't mean mergeable. My earlier comment (maybe not the nicest / best worded) was mostly me trying to redirect your energy into contributions that have a realistic path to moving us forward, without burning a ton of reviewer time.
And I'm not disagreeing with "WE WELCOME ALL CONTRIBUTIONS IN ALL FORMS" - I'm just holding you to a slightly higher bar because you're not exactly the new kid on the block ;-) Core code is where "it looks fine" isn't enough.
That's fair, and I appreciate the thoughtful response. The LLM point is valid, I lead an open source JavaScript framework and the review burden is something I deal with too, so I get how exhausting large changesets can be for a small team.
I'd rather channel this energy into something that has a path forward, so I'm open to direction on where contributions would be most useful right now. No hard feelings.