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).
I’ve been a happy redmine user for about 15 years. It may not look as flashy as newer systems but I appreciate the consistent UI which hasn’t broken, and someone is doing the hard work of making non flashy but extremely useful things like e-mail workflows, export as PDF, git integration, etc stay working
The UI had very few states/pages. 99% of your time was just on the project page to with every card action 1-click away.
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.
I think, roughly, Tracker was a ticketing tool for developers, whereas the others are for project managers. Hence they have endless configurability, millions of views, forms, workflows, and whatnot, all of which gives project managers something to do that feels like work, but end up weighing down the people doing actual work. Tracker has the bare minimum, with no configurability, so it can't be used in that way.
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!
Yes! Deployed and "validated by users" were on my wishlist, too!
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?
HI personally worked on it while I was at Pivotal Labs (RIP). I loved that the point was to get in, add some stories, aka "bookmarks for conversations", have it opinionatedly setup your sprint by averaging the last few sprints worth of points, and then you got out. I use other tools now and I cringe every time at the complexity. I don't want a swiss army knife of features, I want a tool that does exactly what I need and I don't have to spend hours grooming and configuring and tweaking. Tracker hit that sweet spot.
Yes it was the first popular tracker that was developer centric, specifically agile (arguably Scrum), with story points being a very key (pivotal? pun) feature. It was also extremely opinionated (i.e. bugs don't get points). This made it very predictable and easy to get started on.
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.
Huh, I totally forgot about Pivotal Tracker. There was a phase where every project I was on used it.
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.
I haven't used it in a decade, but I always liked it. It was the first issue tracker that I had used that had strong Git integration, and it made very satisfying noises when you would would push a commit.
It also just felt slicker than Jira; not the horrible laggy mess that Jira was for most of its history.
Can you at least link to some of the efforts? This post is light on details.
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.
What surprises me is that the Linux project is far and away the most successful OSS project (it’s probably underpinning what a couple of trillion dollars of services globally - more?)
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
It's like comparing a strong tough guy who doesn't cut corners and plans for the years ahead and a "drug zombie" who only wants to have better KPIs on paper by the end of the month/quarter/year for a title promotion or more internal political power.
Because 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.
The 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
You know... I was a big Capistrano fan back when I worked on Rails webapps and honestly, thinking back to it, it holds up pretty well. I can't really remember a time when I felt like it actually burned me, and that's not something I can say about very many tools. We had Jenkins automatically pushing dev builds all day long (automatically) and had a Jenkins button to deploy to prod. We did have to use the rollback functionality of cap a few times and it always went smoothly.
I learned to do deployments using custom shell scripts, and then someone introduced me to Capistrano. And i didn't get it at all. Why would i use this tool when i could just write a shell script? What does it save me? My main conclusion was that some people just don't like shell scripts as much as me.
Make that 11 teams! :)
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).
name is good ^_^
Thank you! I'm glad you like it! ^.^
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’ve been a happy redmine user for about 15 years. It may not look as flashy as newer systems but I appreciate the consistent UI which hasn’t broken, and someone is doing the hard work of making non flashy but extremely useful things like e-mail workflows, export as PDF, git integration, etc stay working
Too bad its UI is ugly and its update procedures make me nervous. It needs a rewrite.
What made Pivotal Tracker so popular? It had story points front and center, was that it?
The UI had very few states/pages. 99% of your time was just on the project page to with every card action 1-click away.
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.
I think, roughly, Tracker was a ticketing tool for developers, whereas the others are for project managers. Hence they have endless configurability, millions of views, forms, workflows, and whatnot, all of which gives project managers something to do that feels like work, but end up weighing down the people doing actual work. Tracker has the bare minimum, with no configurability, so it can't be used in that way.
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!
Yes! Deployed and "validated by users" were on my wishlist, too!
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?
HI personally worked on it while I was at Pivotal Labs (RIP). I loved that the point was to get in, add some stories, aka "bookmarks for conversations", have it opinionatedly setup your sprint by averaging the last few sprints worth of points, and then you got out. I use other tools now and I cringe every time at the complexity. I don't want a swiss army knife of features, I want a tool that does exactly what I need and I don't have to spend hours grooming and configuring and tweaking. Tracker hit that sweet spot.
Yes it was the first popular tracker that was developer centric, specifically agile (arguably Scrum), with story points being a very key (pivotal? pun) feature. It was also extremely opinionated (i.e. bugs don't get points). This made it very predictable and easy to get started on.
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.
Huh, I totally forgot about Pivotal Tracker. There was a phase where every project I was on used it.
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.
I haven't used it in a decade, but I always liked it. It was the first issue tracker that I had used that had strong Git integration, and it made very satisfying noises when you would would push a commit.
It also just felt slicker than Jira; not the horrible laggy mess that Jira was for most of its history.
Related: "Pivotal tracker will shut down" - https://news.ycombinator.com/item?id=41591622
Can you at least link to some of the efforts? This post is light on details.
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.
They're each linked from the story url.
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/
What surprises me is that the Linux project is far and away the most successful OSS project (it’s probably underpinning what a couple of trillion dollars of services globally - more?)
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 …
It's like comparing a strong tough guy who doesn't cut corners and plans for the years ahead and a "drug zombie" who only wants to have better KPIs on paper by the end of the month/quarter/year for a title promotion or more internal political power.
> I do wonder why …
Because 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.
They do have a bugzilla. I can easily picture Linux's and Gentoo's bugzilla outliving the universe's heat death.
This was recently posted:
Separation of Concerns in a Bug Tracker [2024]
https://news.ycombinator.com/item?id=43296422
Not a single open source solution in the bunch.
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.
Second one in the list is AGPL. Did you miss this, or are you making an "agpl-is-not-open-source" argument in disguise?
It's a weak open source license tbf.
I am feeling nostalgic just looking at this.
The 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
cap production deploy still reigns king in some dark corners of the world. Also Hotwire is awesome if you havnt had a chance to check it out.
capybaraaaaaaa
what a nostalgia proc
I think this was Capistrano, but you're right I that's quite the throwback as well.
You know... I was a big Capistrano fan back when I worked on Rails webapps and honestly, thinking back to it, it holds up pretty well. I can't really remember a time when I felt like it actually burned me, and that's not something I can say about very many tools. We had Jenkins automatically pushing dev builds all day long (automatically) and had a Jenkins button to deploy to prod. We did have to use the rollback functionality of cap a few times and it always went smoothly.
I learned to do deployments using custom shell scripts, and then someone introduced me to Capistrano. And i didn't get it at all. Why would i use this tool when i could just write a shell script? What does it save me? My main conclusion was that some people just don't like shell scripts as much as me.
Of course! MongoDB is web scale!
I remember this meme. I was always in the camp of choose Mongo if you hate your data. But, I'm an everything in Postgres since 2001 type.
BSON. Massive duplication of object keys in requests and responses at least.
Also reminds me of tnetstrings and Bencode.
> BSON. Massive duplication of object keys in requests and responses at least.
Can you expand on this, please? Why is BSON bad?
Serious question, Grunt or Gulp?
Those were the dark days of JS as far as I’m concerned.
I still use gulp for a side-project: it works and it’s simply not worth the effort of replacing.
But I remember back in the day immediately preferring gulp to grunt once I became aware of it.
I'm more interested in MilkyTracker replacements.
Something that worked well on mobile would be nice.
where do those team coordinate and track their backlogs and sprints? ;)
Pivotal Tracker was built bespoke around Extreme Programming so no sprints.
And obviously...they track everything in the tools they're building. :)
Some vibe coders incoming after seeing this post?