Development pace (roadmap for 2025?)

I see some additional changes were made to the roadmap, but none that include the features mentioned here.

Also, I saw on another post that Any hired an additional programmer to work on opening the API. That’s great, and I hope they do a great job. How much do you think it would cost to hire another programmer to fix Anytype’s lack of RTL-language support? I’d be happy to open a crowd-funding page for it, just give us a goal/target and open a position for a suitable candidate.

Don’t worry, the other 3 features will be added to the roadmap as soon as we figure out when we’ll have the time to work on them.

Good point - the roadmap isn’t a list of things to do. It’s a list of things for which resources and time have been allocated.

When I was a project manager, my project plans never included anything that wasn’t full resourced and scheduled

I hope so!
I Anytype does all that is on the roadmap right now, and not just in a “MVP” way, then 2025 looks like it will be great for Anytype.

I know this has been said but I will still believe that someday it will happen somehow.

What about Excalidraw plugin for Anytype? IMO it would be excellent combo…

100%

And charts please? :pleading_face:

Keep your hopes down and patience steady. If we’re lucky we might get transclusions and formulas before 2026; charts could follow in 2026, but considering how many other features more fundamental features are missing it’s more 2027+ territory, if lucky.

I used to suggest people write Feature Requests and vote on them, but frankly, that’s a waste of time, as they have zero weight in development decision-making.

P.S.,
Notion getting forms is also pretty exciting for me. It’s one of the few things I still rely on Google for, and I’m happy to transfer my event RSVP management to Notion. I don’t see anything of the sort reaching Anytype before publish-to-web is established, and that too isn’t on the roadmap for '24-'25, so again it’s more like '27+, if lucky.

I don’t subscribe to this point of view.
The devs have implemented a dozen or more FRs I’ve made.

You must see the difference: there are some (even frequently requested) FRs that are a bit tricky to implement.
Some planed features depend from other things that need to be implemented before.
That means, the count of votes for a specific feature is not the only parameter for a fast implementation.

Especially transclusion is a very complex thing with lots of dependencies.
It’s not only a bit of code you could easily shove between some other lines of code. You need to rework lots of other things all over the whole app to integrate it.

It feels in deed unbelievable that Anytype isn’t able do do even simplest math.
But I think the devs try to avoid quick shoots which become a ballast later, if the app grows further. They seemingly try to find solutions that can last forever.
That’s understandable. The users would cry if there would be a half baked new feature that later needs to be completely replaced and many existing Objects wouldn’t work anymore.

I disagree with the idea that writing feature requests and voting for them doesn’t work. On the contrary, we listen and optimize based on user feedback.

While estimating progress using a PAS works well for linear processes, it might not be accurate in our case. There is a lot of underlying work happening that will allow us to move at a faster pace.

We are transitioning to a new underlying database (GitHub - anyproto/any-store) which could dramatically increase the pace of development and enable us to deliver complex features like transclusions and formulas much faster. However, I do not expect these features to be ready this year.

P.S. Not everything is on the roadmap (for example, “publish to web” is currently in development).

So many good news :heart_eyes:

As much I want features like charts, or canvas because I’m visual note taker but these easily can be delayed for versions after the main release of the app. all anytype team need now to just maintain what already exist like more improvements to the collection/set and merge them, more improvement for relations, editor experience, over all the interface and much more.

And because I’m not fan of adding completely new feature while the app highly needs to focus of to improve the structure or it will end up like the web clipper which’s not efficient.

I think it’s always fair to recognize the fundamental differences between Notion and Anytype: Local First, Offline Mode, End-to-End Encryption.
I am sure that these premises make everything much more complicated in terms of programming.
To date, Notion has not even commented on whether the frequently mentioned desire for offline mode or even self-hosting will ever become a reality.

By the way, that’s why I recently switched to Anytype.

It is always a question of what you actually want and what compromises you are prepared to make.

I think we should get our hopes up and yes, I do believe that the impossible is possible!
Otherwise wise we would never get anything done. It takes great belief that you can achieve the impossible. We limit ourselves too often. I am not saying we should feel bad when we miss our goals but instead keep an upbeat positive attitude and keep moving forward.

I know that obsticals are along the way but when we aim high, even if we don’t reach our target, at least we get closer to it.

I am just saying this because I do believe that the anytype team is moving forward and that they do hear the heart of the community through the forms.

Thanks for providing a cli interface :smiley:

@anton May I know why not tabs? I also hear you saying in the Town Hall about split screen but not tabs. I think this is a mistake, there are more use cases of tabs than split screen. If someone wants split screen, they can easily open another window and put them next to each other; chances of someone needing more than 2 split screens on the same window is so little. Whereas for tabs, there are a lot of people that open multiple tabs (more than 2) within the same window to get to it later, and instead opening multiple windows to get around this is absurd. Between the two, most people would vote for having tabs instead of having split screen/multi column and I’ll show proof.

This is a solid example showing how the Anytype team is not listening to the users, and doing the exact opposite. Go to Any Requests? and look at the feature request for adding tabs, and compare that to the feature request for having split screen. You will see that the request for adding tabs is almost 6x more than the request for adding split screen. To bring it further, the request for adding tabs is only brought up 1 year after the request for adding split screen and it already surpass the amount of votes by 230. What is the use of the Any Requests? category if the Anytype team does not care about the votes there to see which want is requested more? I’m dumbfounded by how this can happen.

The decision to add split screen instead of tabs highly goes against what you said in the later post in reply to @sofalakatino’s post about voting in feature request being a “waste of time”:

Literally facepalm. This topic thread alone has more people requesting for tabs than split screen and it all got ignored. :man_facepalming:

Yupp, Tabs are also for me one of the most missed features.
It would make the daily work so much more fluid!

Of course, you can know why. Some features have a big impact on navigation and UI, making them difficult to reverse once implemented—tabs are one of those features. While tabs are one way to address ‘getting to it later,’ they’re not always the best solution for that need. So, the reason we’ve postponed this is that there are other, more pressing problems to solve - like fixing primitives and basic UX. The ability to easily work with two objects at the same time is a different issue, and we’re solving it with the split-screen view. So, it’s a different solution for a different problem. Does that make sense? And why was this prioritized over tabs? Because we found a good solution for this problem and have confidence in it. Does it mean that tabs would not come - absolutely not.

Simply implementing features based on votes alone would be a bad move. Our job is to deeply understand problems and provide the right solutions, not just chase numbers. Do votes matter? Sure, but other factors matter too—like how hard it is to develop, how well it aligns with our vision, and our confidence in the solution.

And look, statements like ‘facepalm’ don’t help anyone. Let’s keep it constructive and skip the unnecessary jabs—nothing productive comes out of that.