Just thought I’d re-visit this issue and put forward a balanced argument.
The original question here (and raised on a number of other threads also) is: should Roon publish their development Roadmap so that users (and potential users) can view it and contribute?
A “Roadmap” is a blueprint for what is planned for the software in the future. It would include lists of bugs to be fixed, new features to implement, changes to be made, etc. It would also include some form of priority for these items and potentially a planned timescale.
What has been happening so far, and what is great, is that the Roon team have shown a high level of interaction with users on these forums, and have usually been fairly clear in answering questions in relation to bugs or feature suggestions. Indeed, there are “support” and “feature request” sub-forums for these purposes.
What has not happened so far is the publication of a more formal Roadmap made available to the users (though the Roon team themselves will be using some form of Roadmap to manage the software development).
I imagine that there are various options and online solutions to creating such a public roadmap. As an example, this is what Next Audio Labs have done with their Rekord Buddy software:
They are using Trello, an online service which is a “free, flexible and visual way to organise anything with anyone”. They have a colour-coding system for bugs and features which denotes whether an item is proposed, under consideration, planned, complete and ready to be implemented, or rejected. There are most likely other similar and superior solutions online.
So, should Roon make their Roadmap more explicit in this kind of way? Let’s look at the pro’s and cons (many taken from this and other similar threads):
PROS
- A central place where users and potential users can view the development plans for Roon, including bugs, planned features and other developments.
- No need to scour the forums for a particular issue or request, or to duplicate requests of comments (there is a lot of this duplication on the Roon forums).
- Greater transparency and potentially greater user input.
- Less ambivalence and repeated questioning about issues on the forums. Promotes patience on the part of the users, as they will be aware when a particular feature request has been accepted for inclusion.
- Potentially a rough timescale for feature inclusions or subsequent software updates.
- Users (thought not all) (who have paid a relatively large sum for the software) want it.
CONS
- It may not be possible to stick to any published timecales due to IT or other issues. Note - this appears to be the main potential con that users have mentioned on these threads.
- It may not be possible to include a feature or make a change that has theoretically been accepted (and as danny points out, purchasing decisions should therefore not be made based on the Roadmap).
- The potential for a more explicit Roadmap to promote argument within the Roon community.
- It may require more work to create and maintain such a public Roadmap.
- Things have been going pretty well so far!
I have tried to be fairly comprehensive with these lists but feel free to add other comments.
As mentioned above, the main and most consistent con mentioned on these threads is the issue of timescale. There have been concerns that if a Roadmap is published with potential timescales, it would promote impatience regarding features and disappointment when timescales are not met.
Overall - if these cons can be adequately addressed, then given the potential benefits it would seem the right thing to do to publish a more explicit Roadmap. In almost any business, improved communication and improved transparency are valued. I don’t think that Roon is an exception here.
So to address the cons; the Roadmap would have to make clear that in the world of software development, plans and timescales are liable to change due to unforseen factors. The focus of the Roadmap should be on the actual plans (bugs, features, changes, etc) and not on the timescales. Allow the Roon team to work on these features and prioritise based on their capacity and judgement of importance. Like the Rekord Buddy example, a simple coding sytem for features such as: proposed, under consideration, accepted, rejected, under development and completed may suffice, with perhaps a rough indication of timescale only.
I don’t know in what way the Roon team currently manage their project - if they use a particular software that has a similar functionality, or if they work on paper. Ideally they would use software that has the capacity to be viewed online, for maximum tranparency. Otherwise a degree of extra work may be required in making up and maintaining this Roadmap. Anyway, just some thoughts and I think that the Roon team have been doing an excellent job so far.