Totally agree with the comments about stability and reliability as being paramount before change for its own sake. I dont want semi-beta software for my critical applications! I manage to muck up enough through my own efforts. Lol.
The comment about discussing which exit to take, or not, is an apt analogy. We had roadmaps but did not know the exact path we would take until later in the process. The process and discussion of looking at alternatives and priorities in building a roadmap or strategy was what was most useful, not blindly sticking to it.
Good discussions.
And rest assured, though we are all road weary in here, we want to arrive safely for everyoneâs sake. Then weâll get out of the car, stretch our legs, and lay back in the grass for a little while⌠but only a little while. 
1 Like
âBUT please donât rush.â
I think itâs safe to assume rushing is not in the cards.
Just wait for the fury and uproar when everyone finds out that, in addition to keeping everyone in the dark for 10 years, the company selfishly wants you to pay for the next version too! 
I look forward to ponying up the cash for the next version of DEVONthink, whenever that sees the light of day. It has been indispensable to my work for six (or more?) years.
Keep on keepinâ on!
As a newcomer to the DEVONthink world, Iâd like to add my vote for a public roadmap. As has been pointed out previously, a roadmap is not a formal contract, promise, nor does it need to contain hard dates (most donât mention any dates at all). It just shows the public what the company is working on already, and what is currently in the cards for the future. This helps minimise bug reports and feature requests, can help increase the trust levels of new users, and weighs in on the decision of users considering our competitors.
A public roadmap is increasingly becoming common practice - for companies of any size, and whether the software is open-source, proprietary, web-based or natively compiled. Here are a few current roadmaps, for inspiration, showing how other companies approach this - from using a simple text file in a github repository (that gets updated once a year), to Trello boards, to full-blown in-house systems that report in real-time the issues and commits the dev team is working on:
- Obsidian Roadmap
- Sketch adds the current âroadmapâ as a simple to-do list, directly on their product page
- Plutio Roadmap
- ClickUp Roadmap
- LiveCode Roadmap
- VS Code Roadmap
I disagree. As soon as a roadmap is out, it rises expectations. Then, if the next version comes out without a feature on the roadmap, the developers will have to justifiy their decision. Which takes time away from developing and slows down the arrival of new features.
Just because some people/companies/projects decide to go that way doesnât make it right for every other person/company/project. Iâd rather have a thoroughly thought through feature implemented solidly than something that has been added in haste and badly just because it is on some public roadmap.
As to your examples: Iâm quite confident that there are a lot of companies out there that do not publish a roadmap for their product(s). Oracle? Microsoft? IBM? Adobe? Certainly not Apple (given the often sorry state their products are in, they are certainly better off not announcing to be working on anything).
5 Likes
@chrille correct me if Iâm wrong, but you seem to be believe that a company can only work effectively if the work is done in secret: the more transparent they are with their users, the less work will be done, and the more disgruntled users will be. My experience - as well as othersâ - is that the exact opposite is true.
Take Plutio, for example. Itâs a web-based, all-in-one project management tool. The young guy who started it only a couple of years ago had tried creating something similar 3 times before - investing a lot of time and money, and almost going bankrupt in the process. He failed every time. Finally, he decided to change his whole product development process, to work totally transparently and constantly engaged with the users. He started releasing early (unfinished), constantly getting user feedback, and planning the follow-up work transparently. He now has well over 20,000 users, has been featured in Forbes, and has an unbelievably loyal, international community of users - check out their Facebook group. Plutioâs public roadmap includes all the bugs and QC reports received and confirmed by the team, and is updated almost daily. Any user can visit the page and see exactly what the team is working on - and how important it is. They see their reports are being heard, and their feature requests are being officially added to the list. This reduces complaints and enquiries, and increases community engagement. Very few users ever complain that a wanted feature is taking too long, because they can see by themselves whatâs occupying the team - and the other users will often jump in and respond.
Plutioâs success in this space has prompted some of their competitors to follow suit: ClickUp has also gained a public roadmap, as well as weekly email updates, letting users know what the team is working on, and whatâs coming up next. This has helped them retain their users and gain new adoptees in a highly saturated market.
Another example is Sketch, the drawing app. They were loosing massive amounts of users to their main competitor, Figma - who is web-based, more expensive, has a less refined interface, and less drawing features, but excels in workgroup collaboration tools. Putting a public roadmap up has shown their workgroup users that they had not been forgotten, and that team features were indeed in the radar, and actively being worked on.
Just from hanging around here in the forum for a couple of days, I have been able to see that the DEVON team is super responsive, attentive, and clearly very hard working. The team is furiously following up and responding to posts here, providing support and taking in suggestions. I have no doubt that - like the small Plutio team - they must be super busy also working on bug reports as well as those new features. When you have a dedicated team like that, you should not have any fear of working transparently with your users. The experience in the real world shows that users will respond well, understand your moving deadlines better, and help you engage with them in an even more positive way.
Thatâs not what I think nor what Iâm saying:
Iâm well aware of the cathedral and the bazaar. And I believe that public development might work in many cases. While it doesnât in others. Iâm also aware of the shortcomings in many open source projects, particularly concerning documentation.
But Iâm too old to evangelize about this or that way develop. If the DT guys and gals decide to not have a public roadmap, Iâm fine with it.
6 Likes
I fully agree with @chrillek
For me the most important point is that DT actually makes it very clear in their business principles they donât publish release dates.
Now, one can argue whether a roadmap without dates is very different from that, but in the end it is up to the company to make such decisions. As a customer I really like the way they articulate their mission as it is very clear âwhyâ they do what they do. Might all customers stop buying their software (which I expect will not happen if they proceed in this fashion), the company might consider whether their mission actually fulfills a need. If not, apparently it does.
Those who want a different product or different development concept are free to use something else. But most stick with DT.
1 Like
@anon6914418 most roadmaps donât contain deadlines of any kind - in fact, if you have a look at the roadmap links I posted above, only one of them (Microsoftâs) actually has any scheduling at all. Public roadmaps are not contracts, nor promises: they are merely a way for companies to work more transparently with their community, minimise the number of feature requests and bug reports, increase product visibility and/or promote engagement (depending on how itâs used).
A companyâs Mission Statement is not a substitute for a product roadmap - these 2 documents generally fulfil widely different purposes, and customers viewing one are not likely to even be remotely interested in the other. Usually, a roadmap is by design a short-term communication tool, project-specific and highly mutable - e.g. some roadmaps are updated daily. A companyâs mission-statement outlines the long-term (often broad) goals of the company as a whole, which should help administrators in making coherent choices for the companyâs future - and usually are meant to be immutable.
Nowadays, companies use public roadmaps as a marketing tool (cross-publishing updates on social media, sending roadmap update newsletters, increasing interest among prospective new users), and as a communication tool (minimising enquiries by publicly showing current and planned work, and engaging users by openly including feature requests and bug reports).
@chrillek you seem to be conflating having a public map with turning the product with an open source project - and nothing could be further from the truth. Have a look at the links to the public roadmaps I posted for examples of commercial, closed-source products which have many different kinds of public roadmaps.
1 Like
I consider that a vision. A vision describes the goals you want to achieve in the future or the situation you envision in your âmindâs eyeâ if you like. These goals might be relatively easy to achieve if they require only little effort, and thus can be planned in the near future (short term), more difficult to achieve (mid term) or very difficult to achieve (long term). What is considered short term or long term is up to the company, of course, but some companies plan their long term vision in decades.
This is what you might call a road map.
These goals might be easy or difficult, but achievable nonetheless. Once youâve reached them the company should have prepared new ones already to keep everybody working on further development (beside the daily hustle and bustle of unexpected problems popping up that is)
Now, what I consider a mission contains the why of the company. I.e. why they do what they do. A mission usually contains certain (moral) values to help describe the âcorporate identityâ to both the employees and customers. It helps everybody understand what the company is about. It usually encapsulates what founders like @eboehnisch once thought about doing, but now has to be communicated across to many people.
If you look at the DT business principles I mentioned, it describes values like âFairnessâ and âTransparencyâ which I expect and hope will be an immutable part of their identity. It happens to directly link to their vision by the way, with the sentence âWe listen to customer feedback and suggestions; we implement what makes sense and is true to our vision for our apps.â
Those principles also describe their clear standpoint not to disclose the release dates (the goals they want to achieve) as âunforeseen problems may cause delaysâ. Publishing them publicly might also e.g. create to much stress and demotivate people, but this is for them to decide.
My point is: this is them. As they âlisten to their customersâ as described in their business principles, they undoubtedly have read your question and might consider it. But only if they want to of course.
Personally I donât see the point of publishing a road map. As you describe a public roadmap (not the internal vision) is mostly marketing, as it deals with informing people who are not customers yet or hesitant to become or stay one. If they need it, then theyâll publish it I guess. I have put faith in this company for over many years and havenât been disappointed once. But thatâs me.
3 Likes
Agreed. For any users who have used DT for a couple of years, or have used DT intensively for a reasonable amt of time, or have spend serious time in reading the manual, probably donât need any âroadmapâ at all. The map is already in the pudding.
To be fair, for corporate clients, for user who just recently start to use DT and is not aware of the history of DT, or are simply the ones searching for the ideal app may find a roadmap useful. However, given my experience with DT in past couples of year, spending time on the app and putting real data (with backup) into the database is the best way to understand what DT is about. Then, the roadmap is simply the summation of ideas and feedbacks that are expressed in various sources in which are sensible and achievable to the DTâs developer.
The analogy I can think of are Script Debugger, or KM, or BTT, or perhaps a bunch of other excellent apps that are developed by lean and mean developer. Users will request for features, but rarely ask for a roadmap because they know what they are and will be getting once they dig into the app.
A more legitimate concern for a info-mgt system is the continuity of product development and support. However, DT is not based on proprietary file formats like some other apps, so thatâs lesser of a concern for most DT users.
2 Likes