Show HN: 10 teams are racing to build a pivotal tracker replacement (bye-tracker.net)
A lot has changed since the shutdown of pivotal tracker was discussed here. As there were no viable alternatives it seems every month there was a new project popping up. With the last month before the sunsetting approaching, it starts to get exciting who will make it in time, who stays in the race and what the differentiating features of the projects will be.
97 comments
[ 2.1 ms ] story [ 188 ms ] threadThe year is 2012, rails is the hottest thing and mongodb is the inifinity guntlet scaling monster. BackboneJs and underscore were said to replace all jquery and we deployed things with just one command to heroku. The good ol days
what a nostalgia proc
Whether cap or custom scripts, the thing I loved about that is… it’s simple enough that you can fully understand what’s happening. Not just at an abstract level but very concretely.
But I remember back in the day immediately preferring gulp to grunt once I became aware of it.
Also reminds me of tnetstrings and Bencode.
Can you expand on this, please? Why is BSON bad?
I've been quietly working on oknext.io since late last year. If you're looking for an opinionated task manager for yourself and your team, then I'd love for you to check it out!
One thing I love about it is that it sort of takes care of sprint planning for me. No more figuring out how much I can fit into a week - it does that for me, and seeing my progress over the past few weeks motivates me to keep my momentum up.
It isn't just like Pivotal tracker - will likely never be - the estimation is in hours, rather than points. I plan on explaining the thought process behind this decision soon. And it isn't built specifically for software teams - I manage personal and dev and non-dev work tasks with it.
If you do try it, I'd love to hear from you (vishal@oknext.io).
It rose from the ashes of a long list of well thought out names that my family rejected, and then a good night's sleep.
I like the simplicity of your website and the clear screenshot of what it’s about on the homepage page.
Try to keep it like this if you can :)
Same in Safari
If you're into micro-feedback, there's a horizontal scrollbar on the home page.
Microsoft Planner in theory fits our needs quite well, although it has a few features we don't need. Unfortunately it's a bug ridden mess.
Separation of Concerns in a Bug Tracker [2024]
https://news.ycombinator.com/item?id=43296422
And obviously...they track everything in the tools they're building. :)
I’m already seeing parallels to the MeetUp situation: MeetUp hasn’t shut down, but it’s becoming disliked enough that multiple teams are working on replacements. Unfortunately it seems they’re all more interested in doing greenfield work of developing the replacement themselves when it would be more effective in the most dedicated contributors to the various teams were willing to join up and work on one promising replacement.
https://bardtracker.com/
https://www.centralcm42.com.br/
https://lanes.pm/
https://litetracker.com/
https://storytime.team/
https://planisphere.dev/
https://www.kempt.dev/
https://trackerboot.com/
https://www.pivotalreplacement.com/
https://app.velocitytracker.co/
Something that worked well on mobile would be nice.
The killer feature was the UI. When the alternative was basically JIRA, Pivotal was so quick and easy to use. That front page view that let you see every task in a compact list, and easily drag things around to reprioritise was pretty revolutionary.
Now it seems kind of passé but it really was pretty excellent at the time.
It also had an optional feature to cap the number of story-point cards in the sprint column based on an upper estimate of the team's story-point velocity. I.e. if the team can only do at max 10pts of cards per week, that's all you are allowed to queue up in sprint. This could be overwritten to force more cards into the sprint, but in practice it provided a nice safety guard from over flooding a sprint's delivery expectations.
As a developer, i actually wished Tracker had a tiny bit more complexity (eg i want to be able to track items past "accepted" and into "in production" and "validated with users"). But i would rather have a bit too little than JIRA!
Some projects I was on had very large Acceptance queues awaiting various stakeholders. It was a little awkward, and could have been better accommodated.
And, of course, the ability to reject a feature which had displeased or been ignored by users? Or failed to accomplish its business purpose?
Ah, but these connections are just cute ribbons, and would become repressive if enforced as policy. The story to "Sunset Feature X" needn't be linked to its original implementation, no?
This is why I like GitHub Projects. Devs can create and interact with issues and PRs in the normal fashion while project folk drag them between columns and back again all day.
It also just felt slicker than Jira; not the horrible laggy mess that Jira was for most of its history.
I liken PivotalTracker to a Ferrari. It does one thing and it does it well while JIRA is like your 18 wheeler. It'll also get you A-B, but you can bring everything "in case" you might need it and modify it to hell and back. It can even carry your Ferrari. But getting it setup and moving is a nightmare. Even simple searching your history is an exercise in complexity.
Of course as with anything opinionated, if you wanted to do something outside of its core philosophy set, you basically couldn't. For better for worse, this really meant you were at least waist deep in agile's.
When Agile+Scrum first started becoming popular it was very well received because fundamentally it gave a better framework for business to understand how developers worked other than promising deadlines. But, it's success was its own poison well... that's a different story.
And yet the processes they follow are completely ignored for pretty much every corporate project - open discussion on open mailing lists, decisions made by those deep in the weeds, the code as the first front and centre, even the standard git.git workflow is pretty much never used
I do wonder why …
if universe == $HEATDEATH
then
fiBecause corporations are authoritarian in nature, not open or democratic.
If you don't like a decision people with authority over an OSS made, you don't have to work on it. In fact, nothing in one gets made without free consent of the people doing the work. If you don't believe in a feature, but the decision-makers do, they are free to build it themselves.
Exercising this kind of veto in a corporation will get you fired.
Whenever I have some money I think I'll wip one up.
Although to make it super hardcore, I might just make the whole thing a rest API first. You're responsible for logging in via something like postman or insomnia, and then you need to send in your own rest request to update your tickets. I would do this to encourage a true engineering first mindset.
Then I'm going to open source the whole thing MIT. JSON based project management.
When I build FOSS projects I always use MIT. I'd be honored for a company to use my code.
AGPL is a much harder sell to corporate.
I honestly don't see why pivotal tracker gets this much attention?
It works offline with instant interactions and near 1:1 match of features to tracker. (But with a much improved and refreshed UI)
There will be an option to self host as a single stateless executable/ docker container (plus db) and also to do two way sync with github issues, jira, notion and linear. So the company going away should be less of a danger than with pt.
It provides a Kanban board with swimlanes, but the UI is unique AFAICT, because items in the swimlanes can be entire Kanban boards themselves.
Regardless, I'm going to try it for personal projects.
[0]: https://news.ycombinator.com/item?id=43362725
[1]: https://nestful.app
You do realize that any given organization using the tool can just... write a standards document specifying how the tool is (and more importantly, isn't) expected to be used within the org?
Well, to clarify, then, I think that's exactly what the GP was asking: "what's missing from Linear to make it a superset of a project tracker — where there's some particular view you could point your PMs to and tell them to use that view as the project tracker?"
That being said. While I've never used either myself (my only experience with PM tools is with Trello and ClickUp.) I get the impression that the answer to that question is something like the following:
> Pivotal is a project tracker. A project tracker — at least in Pivotal's case — can be understood to be a highly opinionated version of a kanban-board tool, which encodes a lot of domain-knowledge about how an Agile process is supposed to be done. Doing your project management through a project-tracker tool, thus constrains your project-management process to follow best principles that keep your project from falling into certain common failure modes.
> Linear isn't opinionated. Rather, it's a Jira-like "describe how your company's workflow should into the app one CRUD object at a time" tool. Linear might have a kanban-like UI in it somewhere, but that UI doesn't "think of itself" as being "for" Agile; it's "for" whatever the org wants to use it for.
> The axis on which Pivotal can be considered a better workflow tool vs. a plain virtual-kanban-board like Trello, is the same axis on which an online board game can be considered a better "gameplay experience" than a plain virtual-shared-tabletop app where you've loaded in the assets of that board game: the Pivotal, like the online board game, enforces the rules you want to be playing by.
> Linear does not enforce any kind of rules by default; and although it's possible to "teach" it some kinds of rules (mostly in the relationships between types-of-nodes), it's impossible to encode the sort of constraint-type rules that an Agile process is built on, into it. Thus, on the axis on which Pivotal's goodness is measured, Linear offers nothing.
ok but that would mean creating a complete project tracker view as a subview in linear or recreating linear as a project tracker tool and then adding the features not part of a project tracker back in an non obstrusive way. Both are not feasible for linear to do.
> "and be understood to be a highly opinionated version of a kanban-board tool"
no they are fundamentally different abstractions i think this is part of the misunderstanding. a kanban board maps story state to swimlanes and you pull tickets through lanes/ states with your workflow. a project tracker keeps the relative position of stories for most state transitions eg. stories don't move if they transition from finished to delivered. the lanes in a project tracker are an abstaction level above story state.