It’s one thing for a startup to do this while small.
A whole other level of evolution to do it while you’re large. Imagine Apple suddenly publishing their roadmap. This type of organizational neurogenesis done as an adult is impressive.
EDIT: I am in admiration of the change, regardless of opinion on the value of public roadmaps. It’s just rare to see big companies make big changes. Sign of youthful vitality and health, in my opinion.
Yeah. All Cloud deprecations have a minimum of a year notice, usually as an email, ahead of multiple follow up emails as the year draws close. It's in the terms.
Additionally, you can also get this information in the public release notes https://cloud.google.com/release-notes twice-monthly GCP newsletter, and for G Suite administrators in their news area. "Sigh."
While it's only for enterprise customers, AWS has a weekly email containing upcoming launches which are under NDA. It also has what amounts to recaps of recent launches, blog posts etc. Only the launches section is not publically available.
The upcoming launches section is literally just an HTML table with two columns: service name on the left and a brief summary on the right like "Add support for X Y.Y". It's almost funny how so much effort goes into fancy blog design when the "real" news is just distributed through a basic plain text email :)
---
To a certain extent, roadmaps become redundant for enterprise customers too in that you start to influence feature request priorities via your dedicated account manager(s)
Vendors may often prioritise a feature requested by medium enterprise to keep them content since if they don't address their features in a timely manager, they may go elsewhere when their contract comes up for renew.
---
I suppose that's why UserVoice type of forums are always a wasteland because the big players can get all the attention?
It's also behind the scenes so perhaps naturally, the result you're left with is acres of "9999 votes for feature X, submitted 14 years ago" and a Product Owner saying "Sorry, no news to report on this just yet"
Apple is a poor choice, because they consider keeping their roadmap under wraps an not only a competitive advantage, but a core part of their company ethos.
If you want the full-blown thing, there's a whole book called "Inside Apple" which details the whole long-term extremely secretive nature of their business (this was back from the Steve Jobs era).
Apple is similar to Disney in their core business model being anti-golden-rule. Not "treat others as you would like to be treated" but "treat others as you want to treat them, and insist they treat you as you want". Don't care about respecting others' trademarks or ideas, take creative bits from everyone, be super vigilant and protective (even antagonistic) about anyone else who uses any of your ideas.
The claim should be completely indisputable. It's well known that teams within Apple are not privy to the roadmaps of other teams, even teams working on a different aspect of the same project.
Lot of secret projects and buildings in SJC that belong to apple. No Apple logos, sign an NDA in the lobby, meet in conference room outside the working area. It is indisputable.
Which is completely different from Amazon, I’m not even considered an SDE - I am a consultant at AWS - I can get read only access to source code of services if I request it.
The downvotes must be coming from asking about the latter point since it's clearly institutionalized. The former is interesting to ask about though, how is keeping product roadmaps a competitive advantage in Apple's case? Which teams is this especially so, and on which products is it in their interest for the roadmap to be out in the open?
Google provides rather detailed roadmaps for GCP, they are really useful. They are under NDA, but customers should be able to get access. I think this recent "C2C" announcement has link for signing up[1]. I was invited, and your account manager should be able to invite you.
Thank you! We work really hard on the GCP roadmap program, keeping it fully accountable, and pushing against interesting transparency limits.
A public GCP roadmap is also in longer plans but there's a few internal flows we want to improve first. I'm especially trying to reduce the number of sites people need to visit, and want to ultimately see it land in a common place where authenticated users also see the non-public / NDA aspects.
And seconding this advice on access. If you are a GCP customer, your account manager is able to add your account for access. My contact info is in my profile and I can reach your account team if you have difficulties.
My first reaction was very different from yours; the desire to dogfood feels excessive, to me, and negates the point in having a public roadmap in the first place.
Am I wrong for presuming that the people who would most care about GitHub's public roadmap probably aren't even GitHub users?
EDIT: Thanks for the replies, everyone. Seems like I hadn't fully comprehended the range of features available to paying members - given this knowledge, choosing to do the roadmap in this form makes more sense to me.
Am I wrong for presuming that the people who would most care about GitHub's public roadmap probably aren't even GitHub users?
Free tier users, maybe not.
But paying users care very much about what they can expect for their outlay of money in the years to come. Roadmap presentations for paid software are _de rigueur_; they help keep your paying customers on your platform.. They're just not often shared openly like this.
Github has a vested interest in attracting more and more free-tier customers though. Then they go to companies and influence tool purchasing decisions and help feed the paying customer funnel. So this seems like a risk with some postive calculus behind it. It could be that free-tier users didn't know they wanted to know the roadmap, and now that they do they'll be happy they know about it.
> Am I wrong for presuming that the people who would most care about GitHub's public roadmap probably aren't even GitHub users?
I think so. I'm a GitHub user and I like being able to view their roadmap.
Think about it this way. GitHub is a giant piece of software that developers use. Software changes, and developers are particularly sensitive to this. We're constantly fixing bugs and factoring code to support dependency shifts (or choosing to snapshot ourselves at some preestablished point of stability).
Given our sensitivity to change and how important GitHub's product is to our productivity it's crucial that we're not hit with surprises. A properly communicated roadmap helps avoid that -- thought admittedly it does take some work on our part as customers to parse it. That said this is no different than reading release notes and documentation for the software and libraries we use elsewhere in our day to day.
Thank you! We couldn't have said it better ourselves. Let us know if you have any other feedback on what we can provide you to plan better. And thanks for your use of GitHub!
problem is, this roadmap doesn't contain any specifics in contrast whats required from startups. It's just a fancy way of saying "we gonna do more source code versioning stuff".
Can you explain why? I really don’t see the draw of public roadmaps. I buy a product because it works for me now. If there are improvements I need in the future the company either implements them or they don’t. A public roadmap doesn’t improve my experience at all. In fact, I might be less likely to buy the product.
This feels like it opens github up to the vocal minority to scream and yell publicly about features they want. Some of which could negatively impact other users. And github will have to succumb to the pressure of that minority.
I fail to understand how an open roadmap would make you less likely to buy a product. If you compare two products with the same current feature set but one has an open roadmap and one has none - are you saying physical access to a roadmap would deter you from buying that product and instead buy a product that has no roadmap?
A public roadmap functions as a communications tool and sounding board. However, it does not negate strong product leadership or moderation of course.
Interestingly, my small SaaS was using GitHub projects as a public roadmap for the last 2 years already! Even at our small scale it has already proven useful for finding beta users, getting feedback etc.
With Github I’m not so sure. The online mob usually gets what they want. Having said that, the overlap between those paying the most for Github and those demanding the most might be 100%.
> Discussions live in your project repository, so they’re accessible where your community is already working together. Their threaded format makes it easy to start, respond to, and organize unstructured conversations. Questions can be marked as answered, so over time a community’s knowledge base grows naturally.
I can imagine "GitHub Discussions" [0] cutting off a significant number of Stack Overflow questions.
This looks really cool. A sweet spot for certain kinds of questions that people abuse Issues for, but never felt right. Very important things like "what is the best practice for X" or "I have this problem but haven't yet isolated the cause, can anyone help?".
This is quite some timing for me, since the StackOverflow announcement earlier today had me thinking what could replace it. This is a clear, promising possibility.
> This is quite some timing for me, since the StackOverflow announcement earlier today had me thinking what could replace it. This is a clear, promising possibility.
I'm fine with this, so long as the search engine optimisation is there. I often google for an issue with a particular framework or library, and rather than the first result being the documentation, the first result is somebody asking on SO about it. It would be great if the answer is "closer to the source", pardon the pun. It also means that related questions may be easier to find, and you may come across something else of interest while on the discussion page for that particular project.
It also means that rather than building up SO's capital, you're indirectly contributing to the open source knowledge base of a project. It'd be even better if the discussion were backed by a Git repo or something easily exportable so that you aren't tied to Github, though I suppose part of the motivation for this feature is doing exactly that.
Still, SO has been king for too long. And the king's crown has been looking rather tarnished for a little while now.
I really like the idea behind this feature. Being able to add a discussions 'forum' to my main project could be an excellent way to start building a community around the project.
Looking at the Discussions issue page - https://github.com/github/roadmap/issues/104 - it looks like this will be delivered to projects not in the Beta testing group sometime before Christmas?
Out of interest, are there any project admins around who can comment on how easy it is to moderate the Discussions threads? My one concern would be managing flame wars, and minimising inaccurate answers participants may offer each other.
I'm looking forward to GitHub Discussions too. As well as helping foster community and contributers, it's also a clear separation from Issues, where I often see non-dev and peripheral questions being asked.
> Out of interest, are there any project admins around who can comment on how easy it is to moderate the Discussions threads?
There's a soft NDA on people who are in the Discussions beta. It's also early enough that there's a direct pipeline to GitHub Staff on issues that are truly urgent, so it's really too early to say. The Issues moderation things like locking and org-level blocking definitely still exist and work in Discussions, though.
I've seen a few startups (For example https://www.getoutline.com/) using the GitHub Discussions beta as a defacto support forum. I like that use case and it seems like it will help both developers and users.
For devs, you'll get a forum setup without requiring time/money to set up your own hosting, which is big for small or bootstrapped projects. It will also help move specific questions out of your issues section/ticketing system.
For users, it lowers the friction associated with getting support since many already have a GitHub account.
This is welcome, but anyone else feeling that GitHub is moving in the more-stuff-lower-quality direction? In particular I've wasted quite a bit of time over the past year on scarcely documented features and misfeatures around GitHub Actions. (To be clear I like GitHub Actions a lot.)
One example: just yesterday I found out that public images on GitHub Packages Docker registry can't be used in GitHub Actions' jobs.<job_id>.container, since the former is gated by auth for whatever goddamn reason and the latter can only pull from public registries. Think about it, their (probably #1) container-related feature can't use their own registry. Apparently people have been complaining for almost a year now, yet nothing has changed.
I do wish they were holding a slightly higher quality bar on each release, yeah.
My tiny example was the release of statuses. It included a pop-up to tell me it was there -- everyone knows developers find those obnoxious, just let me discover the feature myself. Plus, the feature just isn't relevant to me as someone who isn't actively participating in open source or looking for a job right now. The little animations were also slightly janky, and the button didn't feel like it was in a neat and orderly place - just sort of tacked on so that it'd be seen.
My hunch is that this comes from organizationally overemphasizing shipping something splashy instead of something amazing. Is the company celebrating "discerning people find this to be uncompromisingly good" (even for small or old features) as much as "this thing was noticed by a lot of people and then this other thing was noticed by a lot of people too"?
Overall I feel that under Nat, GitHub has walked this line quite well - just feels like it slips a little sometimes as a natural pendulum swing
I think more-stuff-lower-quality is kind of inevitable, but I am happy with that general direction. I have run into a lot of annoying things like and including your example. This roadmap would be better if it had a simple way to submit and vote for feature requests like other public roadmaps.
Thanks, @ianwalter. We plan on having a public feedback repo soon - but in the meantime, if you want to submit ideas, please check out https://support.github.com/contact/feedback.
My biggest beef with actions there's huge conflation between action and workflow. I've spend many hours swearing at their documentation...
Also I'm not sure it's a great a idea to use their actions actions as it creates dependencies on someone elses repos and Github itself. I feel I should just write my tests in a container, but I think I've hit a wall there pretty quick too.
I love that the issues each share a common format and provide concise yet clear documentation. The concise bit here is key -- I've had trouble perusing similar, open product roadmaps from other products because of the verbosity / level of detail.
Kudos to GitHub's team for doing such an excellent job in communicating and managing the roadmap. Particularly given the size or the organization -- this is no small feat.
It's 2020, the cost of an ipv4 address is more than $20 an address. Can there be some focus to include ipv6 support so that perhaps those people in the developing world who can't afford an ip address can access github and contribute?
Such a mechanism would be an actual meaningful step for enabling access to poorer communities.
> It's 2020, the cost of an ipv4 address is more than $20 an address.
But arbitrary layers of NAT are free, so in practice this shouldn't actually block anyone. I haven't had a globally reachable IP address for any of my computers ever, and yet here I am on the web.
It may not matter in the developed world where this cost doesn't matter because infrastructure is cheap. There are still limits to how much this can scale as a solution no?
For a Country like India, surely this cost will matter especially for it's poorest citizens. The limits of this infinite scaling NAT will matter. That and the cost of an IP which I imagine will inflate much higher than $20 an address.
It's 2020, why isn't this a priority on the roadmap. I think it would have a much more meaningful impact to those that need it.
Are we so sensitive to racism that the word "master" is offensive? There is a task to change the default branch to "main".
Note: there is no "slave" branch.
Intent matters, not the literal meaning of the word taken a specific orthogonal context. Not a single person in the millions of developers ever had a perverse notion of what master branch means.
I like how people are downvoting your comment for simply linking to resources.
This way, we are in a mob rule. No one is independently thinking and questioning. Going against the grain is automatic suicide. Virtue signaling everywhere.
Oh please stop white knighting. The resources spent doing something unnecessary can be better spent elsewhere. No need to break scripts that have a hard coded master keyword in the.
Nobody is offended it's being changed. Nobody is offended it says master either , it's just plain unnecessary and in general doing stupid and unnecessary things is a bad idea because it prevents the person doing so from doing something useful and good
Not offended. The status quo = 'master'. You need to make a good reason to change it. The onus is on you to make a solid case to change the status quo.
I am fine with it, it is just so far fetched that it seems unnecessary and pedantic. It would be hypocritical to target one thing but not the rest. How about also removing the word "Master" from the dictionary? We should go the full 9 yards you know.
What's next? We wanna lobby MasterCard to rebrand themselves? Because everyone thinks that it is a card for the "Masters", right?
Absolutely ridiculous. I also heard some noise about the Chess game and colors of the pieces.
> The status quo = 'master'. You need to make a good reason to change it.
Why, though? As far as I'm concerned, Chesterton's Fence applies, i.e. you need to know the original reason, and then you're free to change it if you've got a better reason than that + the downsides of change itself.
If even I agree with cancel culture, I intentionally want to push back on it because there is no nuance, there is no counter point being heard, there is absolutely no check and balance. It is just mob rule and that's dangerous to free thought and free speech. Immediately, after you read the previous sentence, I bet some of you had an image of me pop up in your mind - "Stupid Trump supporter, MAGA hat, gun loonie and a racist at heart". If it did, you are a danger to the society just like those people that I described.
Soon, you'll have lawyers being cancelled because they're defending the racist criminal who have the right to an attorney. Whatever is going on today is extremely worrying.
> Not a single person in the millions of developers ever had a perverse notion of what master branch means.
Did you ask them all? I also never noted that it could be offensive. But "main" seems to be a good alternative and as long as master still works as a synonym, nothing should break changing it. The only contra to changing it would be the money Github spends on development. But that's their decision. Overall, I fail to see the problem.
I really don't need a lot of fancy stuff in order for GitHub to be valuable to me or my organization. Honestly, I did not find much of the roadmap to be compelling.
For me, the core features that comprise my GH user story are:
- Code
- Pull Requests
- Issues & Labels
We also have limited use of Actions (for check builds) and heavy use of the API/Webhooks for integration with our own custom CI/CD tooling.
In my opinion, the biggest place where value should be added is in these 3 areas above. Some of the simplest ideas are the most powerful. We get an incredible amount of mileage out of basics like issues & labels. If there were additional aspects to issues similar to labels that could further enhance this experience, I would be very interested. Our entire development process revolves around issues to track tasks.
One of the things I've had in mind would be a way to build a markdown-defined webform template that can be used for populating highly-structured issues without requiring the user to edit a complex document each time.
For example, you could have CustomerTroubleTicketTemplate.md in a .github/issue_templates/ path, and then when you go to click New Issue, a down arrow could be provided that pops a list of all defined issue templates. Selecting one would present the user with a webform (as defined in the template markdown) that collects all required fields to create that issue. The issue could be created with labels/assignments/etc as defined in the markdown document. This would likely require enhancements to GFM.
Bonus points if there is some way to expose specific issue templates through public GH pages so that your customers can submit tickets against your private repositories even though they don't have direct access to your issue buckets. I think a very small step in this direction could obviate a lot of use cases people find with products like Zendesk (it would for us, anyways - we just funnel ZD tickets back into GH issues).
It's a longtime practice of Azure DevOps (former TFS) team [1][2] and many from that team are now working under GitHub. Maybe that's a culture transfer from MS.
Kudos to Github for trying this. I'm excited to see more SaaS companies "call their shots" and provide insight into their roadmap plans. It seems like a natural evolution of the industry.
For any enterprise SaaS businesses trying this at home – keep in mind that any product information that you publish publicly can and likely will be used against you by a competitor in a sales cycle at some point, fairly or unfairly. This might still be worth it overall, but is a real risk that isn't obvious until it happens to you (or you observe your team doing it to someone else).
This is our first time publishing such a roadmap, and it isn't 100% complete yet. More items will fill in over time. But we needed to start the journey somewhere!
Dark mode is coming. The foundational work we are doing first is to replace all our custom HTML and CSS with components that are more readily themable. This will also help us improve accessibility, and help us replace our mobile web site with a fully responsive UI.
Could you please consider open sourcing the frontend JS and CSS? Right now it's impossible to use github proper without these assets being minified and/or proprietary.
Am I the only one who does not care about Dark Mode? I find it neat that someone cares about it enough to mention it is missing, over lots of other features that are missing.
I see it in lots of products and kind of ignored it, but is this a priority for users?
I don't make dark mode part of my choice of whether to use something or not, but given I am using something, I always choose dark mode.
On OLED screens like my phones, black reduces energy use. On regular screens, dark mode subjectively seems to make things easier on my eyes. I also use f.lux and related technologies. I also sometimes use yellow-tinting screen glasses. I have no idea if any of this is scientifically valid, but at this point I can feel my eyes decline significantly as I age. My particular vision is 20/20 but one of my eyes is much worse and this contributes to a lot of eye strain. I also have pretty chronic headaches.
Since my entire ability to make money hinges on computer screens, I will take whatever nonsense option seems, subjectively, to make things easier on myself or preserve my longevity.
GitHub and HN are probably the two things I use most that do not support dark mode natively. My sense is that as far as feature requests go, dark mode typically does not tie up resources that otherwise would be allocated to more functionality-based features. GitHub doesn't need to provision more servers, for instance, in order to implement dark mode. HN already has colour customization, we need only to be able to customize a few other colours to allow dark mode natively.
Particularly for code-related products, not having a dark mode is disrupting. If you run most of your apps in dark themes (IDE, terminal, StackOverflow, etc), having something be light themed can be blinding.
Obviously I can't speak for anyone but myself, but using GitHub Dark[1] has been the single biggest improvement to my experience with GitHub on a day-to-day basis. I have a large monitor, and spend hours a day looking at issues and code on GitHub. Having a dark theme is essential since the alternative is to deal with being blinded when switching from my editor back to GitHub.
You're not, but a lot of users care a lot about it.
I recently worked my way down feature requests enough to reach dark mode for a site I run and users were ecstatic, moreso than they were for big, new features that'd been requested thousands more times. I don't use it personally, but I think it's a "feel good" thing when you have the choice of dark or light mode.
That kind of stuff is exactly why I’ve stopped going “dark everything.”
Some apps/websites are and will forever be WHITE and, if I use dark mode plus max screen brightness (to increase contrast), I’ll be blinded every time I open/visit one.
You know what doesn’t blind me? Using regular white pages with low brightness. Bonus points: my battery lasts longer.
Super excited about auto-merge for PRs. "Today, the workflow for these users entails submitting pull requests and then coming back to the site to merge and delete the branch."
This is a great idea - I use the equivalent all the time in Gitlab.
> We will add an option when submitting a pull request for review to auto-merge it if all checks pass and the pull request is mergeable into the target branch.
IMO they should also make it possible to enable after creating the PR, before the checks finish. That's how Gitlab works and it's really useful even beyond the single author repo they discuss - once you have your approvals and have addressed all the feedback you can enable merge on pipeline completion and move on.
I believe the direction is to keep GitHub focused on where developers want to be, and not become some bloated planning tool for project managers and enterprises
If you're looking for agile power-ups to GitHub Issues, there's a few great options in the ecosystem. Check out ZenHub if you're looking for things like issue dependencies, epics, multi-repo boards, etc. and want to stay in GitHub. GitKraken Boards are also a great option and integrate with their Git GUI.
My team uses ZenHub extensively, but it's not that great for OSS projects IMO. The extra metadata and organization that ZenHub allows isn't visible via GitHub issues, so it's basically just for the core team.
Issue dependencies should be part of the core issue tracker. And GitHub has multi-repo boards, but only for repose in the same org.
whoever or whatever team came up with the personal README's for ones github profile needs to be given the keys to all of Github because no feature in all of my years of using github has had such a profound "cool" factor than this. It will also go a long way to solidify the site as a social network. I see it replacing my resume, I will just send people that link, much like I used to with a personal website.
The roadmap is nice and it's nice that we might get to see what is going on or coming up and maybe have a say in it. This seems a lot like what Gitlab is doing though, so perhaps they're trying to get some of Gitlab's goodwill?
From a certain perspective, this is what the :+1: and :-1: reaction emojis are for, although I haven't checked to see if those are accessible via the issue API
Another great roadmap I enjoyed reading through was the one of IPFS. Formatted somewhat differently (one long document) but still just gets me excited reading through it while communicating key objectives and milestones.
A long requested feature for private repos is going enterprise first. Not sure why, I don't know if this is purely business decision or if it has a technical reason
Great to see a roadmap so we have an idea what's coming.
A little OT, but what I'd love to see on the roadmap is rolling back the recent UI changes! Rounding every corner in sight just looks wrong; it doesn't "suit" GitHub. The accompanying layout changes also don't help.
I reacted the same way during preview, and after living with it for a few weeks I still feel the same - the recent UI changes still look and feel odd, like it was little more than busywork.
Interesting to see people opening issues for things they want when nothing in the README suggests that Github was seeking community input. I realize that this is possible due to the fact that it is an open source repository, but its possible the issues could get flooded and this repository becomes less useful?
Was actually hoping there would be more community features on the road map. I know I'm in the minority, but the promise of social coding is still out there waiting to be realized and more ability for open source projects to collaborate in diverse ways would be welcome.
> Existing issues are currently read-only, and we are locking conversations, as we get started. Interaction limits are also in place to ensure issues originate from GitHub.
In other words: “our issue and community management functionality does not scale.”
It looks so bad... there are great tools out there that are built specifically for sharing your public roadmap with your users. Using GitHub for this is very rough on the eyes, and just bad for usability.
Honestly, do not care, at all. The fact that they're doing it I think is awesome. So many large cloud providers (cough, GCP, cough) are so loath to give any visibility into their upcoming roadmaps, and it's extremely frustrating. I totally understand priorities may change, but having a general roadmap lets me plan much more easily.
Sad to see that the biggest missing feature of github.com (and actually a simple one) is not on their roadmap, not even considered in the "future" section...
FFS, people who come to the US (illegally I might add) end up in a place like that because they're deliberately underfunded. That is not a concentration camp. Instead of making a rash, politically motivated decision, consider that having GitHub access (and loads of other services) removed could actually make life worse for the people there because they're less able to effectively work with so few resources.
ICE's budget this year is $8800000000. Do you really think they separate families and gas their detainees with HDQ Neutral because they simply can't afford to treat immigrants like humans?
They don't gas detainees, that's seriously unfounded.
That's a lot of money, but still not enough to cope with demand. Not to mention there's constant pressure to reduce the budget just like because functionally under US law these people are considered criminals, and people would rather that be spent on Americans instead.
> Two advocacy organizations have filed a complaint alleging that Immigration and Customs Enforcement detention center is using a COVID-19 disinfectant on the facility over 50 times a day.
> The report, drafted by Inland Coalition for Immigrant Justice and Freedom for Immigrants, states employees at the Adelanto Detention Center in California are spraying HDQ Neutral — which manufacturer Spartan Chemical warns can be harmful as it can cause skin burns and serious eye damage when inhaled — in poorly ventilated areas filled with detainees.
Please note that Jews in Nazi Germany were considered criminals by law as well, and Zyklon B was for "delousing" living quarters. And I'm sure when IBM was manufacturing punch cards for the Nazis, they didn't want to make any rash, politically motivated decisions either.
Thank you for the links - you've opened my mind a bit here. I still don't think that's necessarily worthy of the word "gassing" given we're in a global pandemic and people aren't being murdered.
> Please note that Jews in Nazi Germany were considered criminals by law as well
The Jews in Nazi Germany were criminals because byzantine laws were created to justify their arrest. Detaining trespassers has been a crime in every nation in history.
What would you prefer to happen?
- Increase the ICE budget and not take away their resources (GitHub, AWS, and all the other boycotts), causing the conditions to be _even worse_.
- Abolish ICE and let potentially thousands of un-vetted people out into the country. People who could have criminal background.
A whole other level of evolution to do it while you’re large. Imagine Apple suddenly publishing their roadmap. This type of organizational neurogenesis done as an adult is impressive.
EDIT: I am in admiration of the change, regardless of opinion on the value of public roadmaps. It’s just rare to see big companies make big changes. Sign of youthful vitality and health, in my opinion.