@Ken_GlassWire, the voting-based wishlist comments in that wishlist should be a separate Topic.
(Edit: @Ken_GlassWire, I assumed that you can split topics but you probably cannot because your not in the Moderator Group nor do you have the Leader Trust Level.)
Instead of voting-based wishlist, I would rather have a functional road map that indicates what the developers are planning to implement: what major features will be added and what minor features they enable.
I don’t think that a voting-based wishlist a a useful tool for managing the demand-side of your business unless you link votes to license types: not a user, free user, paid user. That way you can see such things as whether wishes may bring new users or assist existing users, or whether wishes come from people who are prepared to pay for the feature.
A road map could be as simple as an outline or indented list, with or without indicative dates or version numbers e.g.
Notifications
Email v3.0
SMS v3.0
Clear data
Clear history all v2.0
Clear history for specific day, week, month, year v3.0
…
We’re working on some things that are a bit unexpected and we’d rather not make them public. But things like updating history and other obvious things we could make public. I don’t know if Discourse has a voting feature, let me research it.
If it is unexpected then it probably won’t be a wishlist item anyway.
I was thinking of the published roadmap as a means to show people when their wishes are most likely, if ever, to be fulfilled. It would also reduce the number of posts in the forum because people can review planned features just after they see the current feature list.
I actually prefer the voting – thanks for this, Remah.
It is really not a great idea in a competitive market for developers to pre-announce product improvements or features. Sure, nice for us to know, but introduces many potential problems for the developer.
Public beta is a different context than traditional closed-shop development. Information which was previously closed is now open because the benefits outweigh the disadvantages. In this case public discussion of planned features meets real needs, increases engagement with potential users, and enhances the reputation of GlassWire.
See this quote by Tim O’Reilly, open source proponent, in the Wikipedia article on perpetual beta
Users must be treated as co-developers, in a reflection of open source development practices (even if the software in question is unlikely to be released under an open source license.)
Even if GlassWire wasn’t a public beta, it is still common to pre-announce product improvements expected for the year ahead. It often happens in product forums just as it does here. If I went through and documented all the suggestions in this forum then I could produce a basic product road map with three categories. That’s all I’m talking about::
“coming in the next version”
“that’s a good idea that we will look at using in a later version”
“we need to research this further”
A simple list would be sufficient to reduce the number of duplicated wishlist items. It increases the likelihood of people staying engaged with GlassWire until the features they want are developed.
I’d be interested to know more about the problems you foresee. What competitors and what advantage would they gain? What “potential problems for the developer”?
There’s not much competitive advantage in getting that information. None of these ideas are unique to GlassWire and non of it is rocket science. Most of these ideas have been suggested and requested in many other contexts. If I were developing a network security and monitoring product then I could logically develop the same ideas.
GlassWire’s key differentiators are already public knowledge anyway. Any developer that wants to overtake GlassWire would have to make a significant investment because GlassWire already has a good headstart.
I have no real arguments with what you described here. My idea of your “roadmap” from your OP was more comprehensive – delimited as your describe has few problems and I personally like it. Along with the Discourse Voting feature, it would be a good development tool and “nice to have” for us.
As you say, “competitive advantage” may be too strong, but though Glasswire currently has a good start at this stage in development, the “surprises” might not be so great if published in advance so that other products or potential products have more opportunity to move forward in a given area. I think Glasswire is one of the first (not the only) complex visual display of the very complex networking arena. Most other applications that I’m aware of (and it sounds like you may well have a much more comprehensive view than I) are far more table-based – like traditional network analyzers. They and new potential products have great opportunities to develop appropriate GUIs and reduce Glasswire’s market impact.
By “potential problems for the developer”, I mean the issues Glasswire already has with users demanding more and more features and platforms along with release dates. In addition to increasing interest, all this also sets up expectations that may well not be appropriate. Glasswire must control its own development cycle pretty much without regard to user demands or previously established deadline expectations. Rushing product to market is a path to perdition – pressure packed for development and horrendous for customer support. Obviously all development shops must balance this, but public roadmaps have the potential to become overwhelming obstacles.
These are the facts of a competitive market, I know. Growth depends on meeting and exceeding expectations.
With that, I agree that having to search for previously released information throughout a forum is not advantageous to either developrment, support or the consumer – any more that having search for and “stitch together” operating information is for documentation.
I’m not getting into internal personnel management at all. Glasswire appears to be a small shop with growth expectations – “real world”. Perhaps they can be all things to all people, but few survive that experience.
