Regarding Asana and Instagantt:
Most important question first: yes, @danielguajardok knew that our Timeline feature was being developed, and worked closely with @Jeff_Schneider and even some with Justin. I know that Daniel saw some preliminary mockups very early and working with Daniel was extremely helpful in creating some of our API features. In fact, the start date data model in the Asana product was shaped by Daniel’s experience and feedback from Instagantt, so his DNA is present in Asana itself!
We definitely noticed that Timeline was going to be very close to Instagantt in some ways and wanted to be as up-front as we could, and as we were headed to release Timeline we were happy to see that Daniel was moving to make Instagantt less dependent on Asana (such as developing his standalone version). This is fantastic because it not only allows for Instagantt to still be a great app for Asana but allows him to separate it from some of the restrictions and assumptions of the Asana product itself, which I know has held Instagantt back from time to time.
In general we’re strong advocates of sharing as much as we can with our developer community, doubly so when something on our roadmap will affect their apps. We really want to give visibility into what exactly we’re building so our app creators can have the time and insight into how to pivot or adjust. There are definitely challenges here, however. Some of these are obvious, such as risking sharing a roadmap that might change as we build out and test features, and others are not so obvious, like integrations we build being under another company’s press embargo. This happened with our Gmail integration, for instance, because Apps for Gmail was still under wraps on their end.
Since this is actually pretty complex and can require buy in from a lot of parties across Asana, it’s been less about following a concrete policy and more about keeping the lines of communication as open as possible on a case-by-case basis. This gives us a lot of flexibility in cases like Timeline / Instagantt, but does have the unfortunate side effect that we don’t have a hard-and-fast rule we can share for every case. Regardless, we do have a policy of “Transparency by default”, and it’s only when we feel like we’re constrained that we couldn’t be super open with our developers, and it frankly leaves a bad taste in our mouth when we have to do that .
Finally, yes, please do build apps for Asana! Since we shared a bit of a forward-looking vision in that video, I hope it’s a little more clear where the potential and the risks are for Asana apps (for instance, I would caution against building something that looks like the product/portfolio management features that JR talked about in the video ). To be clear and head off an impression that you didn’t really ask, but which we keep in the front of our minds a lot, we absolutely don’t view our app community as a source for features we might build into Asana at the expense of our developers’ time and effort. Sometimes what shows up on our roadmap (which is built from user feedback and our user research teams) ends up being in conflict with an existing app, and we always try to keep an eye out for when this might happen. I’m hoping that we can get even more open with where we’re going in the future, and as always, feel free to ask for feedback on app ideas here on the community or at firstname.lastname@example.org. We’ll try to communicate as much as we can about whether or not an idea sounds like it might get a little to close to potential Asana functionality before our developers invest time and money into building an integration (even if we might be unable to share specific details).