Background Service

[calm blade]

The background service was promised Soon™ after the 80HE launch as a way to provide additional utility to the light bar, automatic profile switching, and probably more features that I'm forgetting at the moment.

It's been a year since the 80HE release now, and the background service promise still has not been delivered on. Wooting has delivered excellent software in the form of the Wootility, but to simply not deliver on the promise of the background service after an entire year - now coming up on another major product launch - is disappointing.

My suggestion would be to set clearer expectations. Provide a rough estimate (quarter?) for when its initial release is planned, or if the project is on the backburner and not currently in development.

You have earned the trust of your customers through transparency around other issues in the past, but this is a bit of a sore spot for the folks that were looking forward to this feature and are still waiting.

Thanks for taking the time to read and consider.

• @calm blade

[dire minnow]

Soon™ was funny at first, but a proper ETA would be much better, yeah. A bit of transparency about the bottleneck that is software development would also be nice. I don’t think software development continuing at this pace is sustainable enough to maintain the “best software” selling point. I said the same thing on stream, but it really does feel like software isn’t the priority anymore.

I understand what Calder said about software including the webshop, but to be quite frank, as someone who already has a board, I don’t really care about the website. Actually, the ordering experience is quite burdensome to me. From having to click “Continue” a million times, to scrolling around the globe 50 times, to 17 order summaries, and that’s just to get it into your cart. It might be nice for new customers (who are probably the target anyway), which makes sense.

[raven gorge]

You should imagine how frustrating it is internally when these items continuously need to be set on pause due to an urgent development (recent example, counterfeits) or pushed back due to a discovered impediment for implementation.

That said, it's not a good excuse for our communication outwards and how in general we communicate on our software updates. If we would hold ourselves better accountable to a clear (public) software roadmap and communicate how that roadmap gets influenced, even if it means communicating repeated delays, we can at least paint a clearer picture of priorities and expectations.

I don't have an immediate answer to how it changes (or how to make the right changes internally), but this type of communication is a good motivator to surface the motivator to make the change.

Regarding the software priority, it's still there, but my explanation on the stream probably lives stronger internally than what externally can be noted.

We have a dedicated team for Wootility & firmware that isn't side tracked on other software needs. Expanding that team always requires a runway, as every new developer needs time before it can become effective and self reliant on bringing functional feature to end users without breaking. And as we expand our software features, the overhead also increases due to increasing complexity of features, compatibility across boards, maintenance on existing features that become wider and wider, and the exposure to end-user where 1 small issue can blow up. This overhead also slows things down a lot.

The above can cause periods of time where there is less activity with exciting new features, making it feel it's stalling from an outside perspective.