Pivotal Tracker will shut down | Hacker News Reader

Pivotal Tracker will shut down

pivotaltracker.com

311 pointssandinmyjoints263 comments

Free business idea: clone Pivotal Tracker as a solo dev / small team.

People often ask: how do I find business ideas?

Well, here you go: many people publicly saying how they love a product that is going away.

This is a validated product: people were paying for it. Apparently quite a lot of people. It doesn't get better than this.

All you have to do is to clone the product. You can literally market it as a Pivotal Tracker clone. It's not like VMWare will care.

You can research companies currently using Pivotal Tracker and build a database for cold calling / e-mailing when you have the product.

It's also a product that is doable as a single person or very small team. With modern technologies (React or Svelte, hosted databases etc.) it's relatively simple to clone.

Staying small is important: those businesses topple over when revenues don't justify expenses, especially if VC funding is involved and VCs are pressuring for going big or going bust. Or when a profitable product is acquired with the hopes of growing the profits but they don't grow.

Stay small to keep expenses in check and you can build a profitable company.

This is a bootstrappable business: a $100/mo Hetzner box, backend in efficient language (Go, C#), front-end in Svelte or React and you can serve lots of customers. The rest is your time and hustle.

Given that it's impossible to sign up, it looks like most prospective cloners will have to learn all the features by watching videos and learn about the exported CSV format by asking former customers for their CSVs.

If anyone is making a clone, feel free to reach out to me. jim.jones1@gmail.com

Previous user of Pivotal Tracker - I'll tell you everything that I loved and hated about it.

I know a couple other devout users as well that I could introduce you to.

I’ll reach out. I am planning to build it for my company

Most people probably have a PT account lying around or can find a friend with one. I just checked and my account from 6+ years ago is still active.

The biggest risk: people are going to flock to Linear, which is the next best thing.

You don't need to capture all of them, just enough to get to profitability. That might be a very small number, for the right minimal viable replacement.

Totally, naysayers may be trying to eliminate all risk in something by a secret idea no one has done.

When in reality, there is no risk free anything.

It's been wild to see linear get clunky and slow over the last year or two.

Ah, I do love the smell of fresh optimism in the morning!

I think the biggest challenges are that a) the vast majority of solo devs capable of pulling this off quickly are well-employed, and b) the timeline for MVP++ is effectively January 1st, else the migrators will make different decisions.

And that as soon as migrations happen, your storage costs will balloon, so you need a billing strategy on launch.

> And that as soon as migrations happen, your storage costs will balloon, so you need a billing strategy on launch.

Unless people somehow figure out a way of hosting stuff somewhere else than Amazon/$host_that_charges_per_mb_transit (Hint: they exist)

Considering it would have to be a lean operation (assuming bootstrapped), then figuring out basic stuff like "We don't want to pay per MB sent" should be a pretty high requirement.

What hosting providers would you recommend?

Both OVH and Hetzner offers unmetered connections for their dedicated servers, only had good experience with both so far (besides when one of OVH's data centers burned down, but hoping that was a exceptional situation)

Backup to Backblaze B2, or, depending on architecture, rely on their object storage for hot data (depending on data cache and tier requirements). They partner with Cloudflare for free egress (on the Backblaze side) of public content as well.

https://www.backblaze.com/cloud-storage/pricing

https://www.backblaze.com/blog/backblaze-and-cloudflare-part...

Cloudflare’s subscription agreement for self-serve accounts limits serving non-HTML content, including "video or a disproportionate percentage of pictures, audio files, or other non-HTML content."

Which seems to be a fine fit for a project management SaaS solution. If you have an origin with non text content, you can front it with Fastly or pay Cloudflare something enterprisey (which you should be able to do once you have traction). Regardless, this is an inexpensive content distribution and object storage architecture available vs AWS egress costs.

Can’t you embed images in html/js as base64 or binary?

In Europe. Hosting for North American customers is a completely different story.

You can use IOFlood for something similar to Hetzner (if a much smaller operation).

I'm fairly sure Hetzner only host their dedicated from Germany or Finland, yeah. But OVH has dedicated servers in Europe, America and Asia if I recall correctly.

All true, but I think we might underestimate the amount of data sitting in Pivotal.

I don't think you'd have to consider migration all the data from Pivotal, but lets assume 10% just in case? Lets say that's 100TB in total (on disk), which you could host with 10x storage boxes from Hetzner, 24 EUR each per month, so 240 EUR in total, which includes 10 unmetered connections (1 per box).

> I don't think you'd have to consider migration all the data from Pivotal...

I do. You might not have demands to migrate all data from all of your potential customers, but far, far more people than you might expect treat their issue tracking system as a system of record and external memory for a HUGE assortment of things.

One hugely (and obviously) useful query chain that such a system answers is "Hey, this customer problem sounds familiar. Did we investigate it before? Did we solve it? If so, how? If not, why not?". For long-running projects, it is impossible to select the correct 10% of data to retain to also retain the ability to reliably -er- service those query chains.

Obviously I meant 10% of all customers would hypothetically migrate from Pivotal to this new imaginary service, not that 10% of the data from each customer would be migrated... So 100% of the data migrated from 10% of the Pivotal user base, pretty generous assumptions I think.

> Obviously I meant...

Respectfully: if it was obvious, I wouldn't have come to the conclusion I did and written up what I wrote.

> So 100% of the data migrated from 10% of the Pivotal user base...

Yeah, maybe. I don't know how large the slice of the Pivotal Tracker userbase you'd be able to retain even if you had a perfect clone. I bet it would be notably larger than you imagine it would be... it's my understanding that it has some pretty rabid fans that used it.

> Respectfully: if it was obvious, I wouldn't have come to the conclusion I did and written up what I wrote.

Sorry about that, I think I assumed some familiarity with moving data around/migrations, and moving 10% of a customers data around from a legacy service to new service wouldn't make much sense in that context.

> I bet it would be notably larger than you imagine it would be

I think being able to capture 10% of existing users is already a very large guess, realistically it would be closer to 1%.

But, without any numbers from Pivotal and actually trying to launch a cloned service, all we can do is guess :)

> ...I think I assumed some familiarity with moving data around/migrations...

I am familiar with this sort of thing, yes.

I'm also professionally familiar with people who seem to think that it's totally acceptable to obligate folks to throw away large fractions of their valuable historical data in the name of cost savings. "Surely you can identify the most valuable 10% of your data!" they say.

Given that I don't know you and what you know, and given that I've encountered a shockingly high number of these fools with a fetish for data destruction, I chose to expect the worst from your somewhat-ambiguous statement... which would ensure that at least one of us learned something, regardless of the truth of the situation.

> I chose to expect the worst from your somewhat-ambiguous statement

Yeah, I noticed that too. Not that my feelings are hurt or anything, but you might end up in friendlier and more productive discussions if you try to stick to the HN guidelines, which includes:

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

https://news.ycombinator.com/newsguidelines.html

> ...you might end up in friendlier and more productive discussions...

Was this discussion unfriendly?

As for discussion productivity: I know that -historically- I've spent TONS of time going round in circles because of unexamined incorrect assumptions that crop up when both sides "steelman" the others' arguments, rather than speaking plainly, clearly, and politely about what they believe their conversation partner to have said. "Steelmanning" can be an acceptable backup strategy, but -IME- speaking clearly and plainly is the strongly preferred strategy between conversational partners who can remain civil.

I assume folks can remain civil in the face of polite questioning and assertion, and switch strategies if it turns out that they can't. To do it in the reverse order is just much, much slower and error-prone.

> Please respond to the strongest plausible interpretation of what someone says ... [a]ssume good faith.

Thing is, that was the strongest plausible interpretation of what you said. I assumed that you were making totally good-faith statements based on your background and structured my reply to be both polite and gather the most information reasonably possible about which of the totally plausible backgrounds you were speaking from with the fewest round trips. Had I not done this, and had you actually been one of those fools who revels in data destruction, we would likely have gone several rounds in mutual misunderstanding, rather than the half-round of solo confusion terminated by your reply that immediately cleared up the misunderstanding.

Anyway... if you have a couple of (6+) free months, you should TOTALLY clone Pivotal Tracker. IMO, the two HARD, HARD parts will be to replicate its ability to work offline, and its ability to integrate incoming changes from the server with unsaved changes on the client. Whoever wrote the data handling system for that program did a really, really, really good job.

> Respectfully: if it was obvious, I wouldn't have come to the conclusion I did and written up what I wrote.

I dunno, that felt obvious to me. Both the idea that you’d somehow manage to get all customers to migrate to your new service, as well as that they’d migrate only 10% of their data sound preposterous.

How about they migrate they easy 98% of data and ignore the hard, large, expensive, etc 2%? Does that sound preposterous?

> ...as well as that they’d migrate only 10% of their data sound preposterous.

Ah, I might be unduly affected by some big data (not Big Data, mind you) migrations that I'm currently involved in, where the Powers That Be are telling us that we have to throw away a huge fraction of our historical data. Well, that and the many times we've had to fight beancounters who popped on by to demand we save the company what amounts to pocket change by throwing away tons of historical data.

(It's flabbergasting how beancounters tend to ignore the price of programmer time when making their cost-cutting spreadsheets.)

I imagine the beancounters have little hope of just making the programmers go away, so they might as well be doing something useful :)

I'm having difficulty understanding your sentence. To whom does the final "they" in your statement refer?

At that price point Hetzner’s dedicated storage servers with enterprise HDDs are cheaper per terabyte and better suited for production work loads.

It might not be as much as one would think. I just looked at their export page and you can only get 6 months of project history data out of their system - I'm guessing that means comments.

Dont OVH and Hetzner offer this? If you dont like bare metal perhaps run Coolify for your vercel like platform?

The best way to pull this off is to bet the tool will end up shutting down and build the replacement before it does. A good example of this is Pinboard: Maciej knew the product inside out, and he knew what being acquired by Yahoo meant. So he started building Pinboard in 2009, caught the various exodus waves from Delicious in the later years (esp. 2011) and ended up acquiring it for $35k in 2017.

I'm confused. Is Pinboard something that was built by this Maciej character? Acquired by him? What was the name of the product Yahoo bought and I assume shut down? FYI I don't see any mention of him here: https://www.pinboard.com/who-we-are

Your comment reads a lot like something you'd say during a chat with friends on a sofa in a café.

wrong link: https://pinboard.in/popular/

Not GP but a rewrite based on what I think they mean:

Maciej knew Delicious inside out, and he knew what Delicious being acquired by Yahoo meant. So he started building Pinboard (a Delicious alternative) in 2009, caught the various exodus waves from Delicious in the later years (esp. 2011) and ended up acquiring Delicious for $35k in 2017.

Thank you for the translation from "person-in-the-know" to "clueless-bystander" :-D

I think Maciej worked at Delicious, which then got acquired by Yahoo. He then created Pinboard as a Delicious competitor, while Yahoo ran Delicious into the ground (as he predicted). Then when Delicious users had flocked to Pinboard, he acquired Delicious from Yahoo.

Developers mostly won't pay out of their own pocket.

The real reason this won’t work is that Pivotal obviously isn’t making good money if VMWare is cool with shutting it down.

If it was some kind of excellent business to be in it wouldn’t be shutting down.

An analogy would be to say that it would be a great business model to clone Redbox now that it’s gone. But it’s not because its competitors ate it alive.

Sure, there are a bunch of Redbox customers that liked the product, but that number was declining.

I’ve worked at a couple places that made the mistake of thinking they could charge a premium for artisanal hand crafted web pages. You get all the customers with deep seated control issues, willing to pay a premium to have everything exactly how they like it, and one by one sticker shock works as therapy and the price they will pay per artisanal, hand crafted webpage slowly declines until it costs you more to run the system than the customers will pay.

And in the most recent case of this I’m aware of, at least two different groups got to sell the company to new suckers before the bill came due.

Can you please elaborate more on this? Price they will pay for changes? Not getting it, is it that the target market is slow forcing owners to lower the price? Doesn’t explain “costs more to run” part.

To a first order approximation, Wikipedia serves everyone the same page. So the cost of pages in Wikipedia is proportional to the rate of edits, not the rate of page clicks and inbound links. Because once I hit Save, the page they display is pretty much the same one they'll show you when I send it to you to ask your opinion.

If I show each user of a website a highly customized, user- and workflow-specific page for the same url based on context and previous activity, then I have to generate it every time ("hand crafted, artisanal web pages") so the weight of the backend is now proportional to traffic.

Amazon.com tries to split the difference. You and I see the same bones of a page for an Apple Watch 10, but little bits load in and show you laundry detergent and me pickles. But Amazon makes more money every time I click on pickles and add to my cart, so there's an expectation that the fractional penny they pay to load the page fragment results in more sales. That doesn't work the same for SaaS applications, so you need to use even this trick sparingly, not build your whole product value statement around it.

For the control issues crack, the paying customer (not their users) is attracted by all the levers and dials, but cannot appreciate the cost using them exposes them to. The development cost can amortize over time, increasing your profit margins and letting you recoup the R&D costs, but the cost of keeping a cluster running cannot. And you've painted yourself into a requirements corner you can't get out of. Eventually their eye drifts to competitors with fewer high-cost, high-value features in favor of low-cost.

What you write seems very interesting, but I'm afraid I'm not fully grasping it. There are few immediate counter examples I can give, and I wonder if I'm missing a point and those are not really counter examples.

Is Gmail a highly customized website? What about Atlassian suite?

Gmail is one, not making money, and two is mostly showing text files that already exist.

Is gmail viable as a standalone company?

I don't know if Gmail could be standalone company, but it surely must be economically viable to run. Proton is a standalone company. Office 365 could probably be a company. But I'm not arguing against you, I'm trying to understand what you say because it seems to be interesting. Also, like you mentioned on a sibling comment, when the cost of showing a page is at current OpenAI level, the feasibility of making profit out of it is highly doubtable.

Does showing different snippets of existing texts for each user,and providing sorting and searching functionality is highly customized in a way that will usually be too costly on the backend to make viable money?

Thanks for explaining and I am sure you have more experience with this type of scale but wouldn’t you say that ChatGPT is an example of “hand crafted artisanal page”, where not only every person sees a different answer but every interaction with the page results a different response. Of course they have a ton of VC money to burn but could it be that technology optimization (especially on the backend and hosting provider) could be the solution to this cost issue as opposed to blaming product features?

I suspect that ChatGPT is more expensive per page view than most and likely all of the dead projects I have worked on, yes. Some of my friends and colleagues would say the same, but I’m sure I can find someone who has worked on a larger pile of cash being used as firewood. Customers will become more price sensitive over time as the hype cycle runs its course. If they can’t aggressively cut costs without losing customers those lines will cross and they will go bankrupt.

"Good money" to a company with $13B revenue a year is a lot different than "good money" to a solo developer. If you can pick up six figures a year in revenue and keep things small enough to run solo, it's a good business for you.

If solo developers could make enterprise-grade work management systems we’d sure have a lot more of them around.

Why? Maybe the market just isn't there for that many work management systems. Or maybe it's not a fun and exciting product to create, so a solo developer isn't as likely to pick it up.

Remember we're not talking about the general case here. We're specifically talking about the feasibility of seeing a specific product being shut down, and then building a clone of it on a small resource budget in an attempt to snatch up their soon-to-be-former customers.

I think solo developers don’t make those systems because they don’t have to. Not because they couldn’t.

Dude billing never a problem. People wanting to pay you is the point of a business

Don't people just use Trello instead?

Pivotal is very different from Trello

This genuinely is an opportunity as you're saying lol

As someone who's built and launched something this big in a few months once upon a time, it feels like way too many technologies, it increases cycle time in ideation land.

This would need to just be a postgres server, extended maybe by things like hasura and supabase, and a single codebase front end for all platforms. If postgres can't do it, don't do it.

Front end... might be flutter. Could be svelte.

Still, being a polyglot agnostic, for the dollar, in speed of development and more importantly iteration, per feature or update, in not needing to create an entire build, environment, nothing really seems to be as complete or as fast as Laravel, as much as it can shock to hear (I am not a heavy user, but considering it).

Different strokes though, its just about speed of iteration.

Great idea! If you're reading this and want to connect about a clone, I'm joel@joelparkerhenderson.com.

> It's also a product that is doable as a single person or very small team. With modern technologies (React or Svelte, hosted databases etc.) it's relatively simple to clone

The core product is relatively simple. But software packages like Pivotal aren't sold on their core functionality, they are sold on their value-adds like integrations, automations etc which take much longer and much more manpower to build.

It just went out of business for… reasons. There are better tools out there nowadays, apparently. Why emulate a sunken ship?

This happened when Mint shut down and a lot of other companies started advertising themselves as a Mint alternative. I'm building something similar too for my own needs (but open source, self host able); sadly it's still very early on so I didn't quite catch the migration wave.

Challenge accepted!

I've built a bunch of web apps for big companies, and I love the hell out of Pivotal Tracker and am crushed that it is gone. I immediately fired up my editor and took some exports from my pivotal tracker account and am working on building a data model to import them into and move from there to the UI.

The base product is pretty straight forward, but there is a lot of nuance to how some things have developed in it.

I will likely not capture everything in an MVP, and I am wondering if there are some key pieces that might be not thought of for an MVP, but you absolutely love about Pivotal Tracker that would be sorely missed in a new product trying to fill it's nitch.

I also see some things that could be broadened and improved that are common in other project trackers. What are some thing you feel pivotal tracker was missing that really made it a difficult sell in businesses?

Feel free to comment on this thread your feedback. I'll be watching it, and also, if any other competitors want to lock horns on developing it, they can have at your feedback too!

If you want to be alerted to when I release this, as well as other things from me, sign up to my email list: https://mailchi.mp/73f113e474f1/robert-kohrs-blog or just follow my blog's rss feed at https://robkohr.com

Well, we took your approach and we'll see where it will take us. We are a company, so we made similar products before in our past, we should be good.

The thing that I always liked about Pivotal is that it was visibly obvious that there was only one queue.

It forced everyone to ruthlessly prioritize and make the hard decisions.

In this moment, do you want me working on this bug, or this new feature? You have to decide - you get one or the other.

It avoided the "Everything is a high priority" dilemma.

+1. It's been 15 years since I used Tracker but I miss that aspect of it.

I LOVED Pivotal tracker for just this reason- it was way more focused. It was hands-down my favorite task tracker. Since most of my projects were code related, we eventually moved to Github Projects which is honestly very similar in being focused. The downside is that non-technical people may need to get a Github account, but it wasn't that much of an obstacle in practice.

An alternative to one big queue is a separate queue for each client (external customers, internal teams, the dev team's own tech debt, etc) as described in "JIT selection from independent streams: An alternative to the “big backlog” of work":

https://longform.asmartbear.com/jit-backlogs/

Each client manages their queue order, so the dev team just needs to focus on the head of each queue. (Of course, the dev team should also work with clients to clarify the requirements for the next few tasks in their queues so the head task will be shovel-ready). The dev team can then choose which queue heads to prioritize and maintain a balance, such as always have one tech debt task and X bug fix tasks in progress in addition to client work.

I also loved that it was adamant about having specific, defined states with no customization. The issue is todo, in progress, done, delivered, accepted… that’s it. Custom issue states are a special kind of hell in JIRA.

> Custom issue states are a special kind of hell in JIRA.

The nth circle of hell looks like a Jira workflow. https://i.imgur.com/dQE9vWn.png and https://medium.com/@daitcheson/you-can-do-better-than-jira-1...

Your honor, he needed killin’.

For the article:

> Whilst I wouldn’t recommend remote team members having to endure a subpar experience, for example during the daily Kanban meeting, is that really a good reason to degrade the experience for the rest of the team, losing out on all the benefits that gathering around a physical board can bring?

Are they seriously proposing _physical kanban board_ as a viable alternative to JIRA? This got to be a joke, right?

(Checks post date, it's 2019... Ah, that explains it)

Worked with a manager who had a physical kanban board in a nearby vacant cube... and had a ip camera set up to it so that the business could go to the IP and see the board. When they had meetings, they'd have the business people on speaker phone and... honestly, we had trouble not laughing overhearing those meetings.

That first one looks kind of reasonable compared to our ‘simplified’ workflow. The full one?…

That fucking state machine page makes me want to shoot someone.

Yes - 100% of the people I saw be annoyed after switching to GitHub projects were the people whose projects were perennially late but also had a roughly 1:1 ratio of PM overhead rituals to actual work. I’ve come to think of it like giving a toddler TikTok – there’s a certain type of person who cannot resist thinking that one more workflow state / custom field will be the secret trick for productivity.

60% yes, but 40% no, because there was nothing after "accepted" - so no way to track "in production" and "validated with users", which are the most important states. You could abuse the earlier states to do that, but then you have trouble tracking internal acceptance. Ultimately, reality just has more significant states than Tracker recognised.

A model that has worked well for my teams is to track story/development state and deployment state separately.

They are fundamentally different things, and you cannot always infer one from the other.

  - "Accepted" is the final state. Deployed to prod and verified. Story is finished and can be hidden from active view.

  - "Delivered" is set by QA when they believe the changes are complete and correct, ready for deployment.

  - "Finished" is set by the developer when they finish, push, and create the PR.

Then we use labels for deployment state. E.g. @staging, @sandbox, @production, etc.

It happens sometimes that a Finished story is deployed to staging in integration build X, but then omitted from integration build X+1, for reasons unrelated to the quality of the changes. In this case the story stays Finished (or Delivered) and we set the @staging label when deploying X to staging, but clear it when deploying X+1.

This works really well, especially after writing some glue code to integrate Pivotal and GitHub and your build/deploy flows.

That sounds more like a disastrous missing feature to me.

A good productivity tool doesn’t dictate how teams work.

I’d rather have a tool that’s more customizable.

I hear Jira is the ultimate in flexibility and widely beloved. ;)

That’s a paddlin’.

I know managers love Jira — a poster child for customizability — esp product managers, but I have yet to meet a software engineer who does.

It simply slows everyone down, but when it's your only tool for tracking work, it's still better than nothing.

Now, the problem with Jira is not necessarily customizability but that it's dog slow, complex, integrations suck, and permissions system is chaotic. Still, I have yet to see fully customizable work tracking system that's better made than Jira.

But also, a fixed set of features does not force you to ascribe the same meaning to them like the authors intended: I've used "bug" tracking systems to manage large projects with great success (including big features, enhancements, but also big and small fixes).

Honestly this is a bit like saying that the dishwashers don’t like the food being served at the restaurant.

Project management software isn’t made for the benefit of engineers, that’s on purpose. The customer is the business, not the engineer who works there.

Any issues with the engineers have with workflow really aren’t the fault of the software, it’s the fault of the project managers/engineering managers’ configurations.

You can’t blame the company that makes the paint for the choice in paint color.

Personally I think the only way Jira has dropped the ball is on page load performance.

And yet every paint manufacturer has hundreds of swatches of various colors that their paint 'comes in', even though there is practically an infinite possibility of colors available.

I've seen many custom JIRA workflows, where you define specific states that can progress to other states. Nearly all of them, over time, were modified so that any state can move to any other state.

And if you engineers don't use the tool you provide, the data in it is useless. Engineers are typically very smart and will just twist any tool they don't like.

Declaration: In order to have accurate state between projects and bugs, everything needs to be tracked in JIRA.

Result: 70% of your Jira stories are now "This JIRA tracks an issue stored in the Github repo, see the repo for current status"

When I ask my Jira admins to enable a set of people to do something on a project, they struggle.

When I create a ticket and don't open it right away before the popup is gone, poof, it's gone into the depths of that project backlog.

If I want to create a multi-project board, oh, now tickets don't have the same statuses, set up a mapping first.

Or figuring out the artifical limits between epics, tickets and subtasks.

And slowness, don't get me started there.

Yes, just like you are blaming the paint shop for only having the basic colors, I too can blame the paint shop for having 1M green hues to choose from.

I hear that the dirty secret of Salesforce is that it’s easier to change your company processes to match Salesforce defaults than to change Salesforce to match your company process.

And before Salesforce the costs were 10x for CRM software customization.

> I’d rather have a tool that’s more customizable.

You think you would, until you do, and by then it's too late.

It's important to have good processes, but the point of all those processes is to help you make things more efficiently. Anything that leads to you spending extra time serving the process directly reduces the amount of real work you can do.

> the point of all those processes is to help you make things more efficiently

I think this viewpoint -- that these processes somehow could increase efficiency if only they were good -- has a lot to do with why engineers dislike systems like Jira, because they will never see the increased efficiency they are looking for.

Let me restate it in a way that I think is a little more nuanced:

The point of systems/processes is to lessen the amount of inefficiency in a group of people working together as that group a) gets larger, and b) experiences turnover.

Nothing's ever going to be as efficient as a single engineer that can build everything with all the details in their head at that very moment. But there's a limitation on size of problems you can solve doing that! So many people working on large problems hate their processes, because each individual person is doing less than if they were in a tiny, stable team, and they can feel this, even if the organization is making great progress.

(And then, at the largest sizes of organization, it's almost impossible to stop the org from crumbling from the weight of its own complexity. People do spend an awful lot of effort trying, though).

I agree with all of that. I understand why there needs to be some kind of rigor applied or else you have a bunch of engineers running around like cats. I'm not saying we shouldn't have process.

But, I've also worked in shops so hidebound that the aim of the organization seemed to be to Follow The Process above all else. Didn't ship anything all quarter? Well, at least we Followed The Process! Customers are screaming? That sucks, but The Process doesn't accommodate their needs this quarter. Principal engineers are leaving? They just don't appreciate The Process!

In my experience, Jira seems to resonate with PMs who adore The Process for the sake of The Process. Lighter, more opinionated systems like Pivotal or Linear seem to help teams deliver features more quickly than teams using Jira to march in line with The Process.

I was on one team that used it and it always felt overly simplistic. But I have to admit that we generally delivered what we committed to each sprint. It was pretty clear when we were overcommitting.

Agreed, every time I clone an issue tracker or to-do list on the go, the first thing I do is deleting the "priority" column.

Unfortunate. Of all the PM tools I've used, I hated Pivotal the least.

It made it easy to do the things that were frequently done.

It limited customization down to a sane level.

And it generally seemed to stay out of the way (significant look at Jira).

I agree. I have been on Pivotal Tracker for over a decade. Still am. Tried Jira and a few others, usually feeling like they are too taxing on the management part.

What are alternatives that are light on the customization and day-to-day management?

end of an era

linear.app seems ok

+1 for linear.app. It's somewhat similar in feel to PT. It's very responsive and has vim style key bindings. We switched a year ago and haven't looked back.

I’ve been using Github Projects. It’s not as advanced and complex as Jira though, but its simplicity and closeness to code and documentation is a blessing for my hyperactive geek brain

The problem with Github projects is that they don't seem to have a super focused direction. They're trying things and then shutting them down after two years: https://github.com/orgs/community/discussions/39106

I do like conceptually the idea of issue tracking living tightly coupled with the codebase, but unfortunately Github can't seem to get it quite right yet.

Thanks for the context.

Ah, I didn’t know/notice any of that, probably because my use case is the absolute minimum:

A project, a few columns, tickets and an assignee field is all I’m using.

I understand most use cases are more complex than mine though.

Yeah I think making PM software is ultimately a trap. You either keep use cases super skinny and make one camp happy, or you decide that you slowly need more customers and end up like Jira. I feel like every PM software is on the spectrum of ending up like Jira, it’s just how far along that journey they are that dictates whether they are interesting to software engineers or not.

I help build Shortcut (https://www.shortcut.com/) and I think it fits the bill of light—but not spartan—on customization and day-to-day management.

To set up a new Shortcut workspace:

1. Sign up 2. Invite teammates, group them into teams if desired 3. Activate the GitHub/Gitlab/Bitbucket integration, so as engineers work via VCS their work in Shortcut progresses automatically 4. Set your workspace's timezone 5. Turn on/off Iterations (sprints) based on your process. Unfinished stories can be set to automatically roll from one iteration to the next. 6. Turn on/off point estimation based on your process

Then start writing Stories (tickets/issues) to track work.

Going further: Stories can be grouped into Epics. Epics can be grouped into Objectives (with associated Key Results if that's your thing). You can put Epics on a Roadmap to "share out" what your team is planning to work on. All optional, based on how you work and the size of your org.

Agreed, as an ex-pivot I really liked PT (relative to Jira et al.)

It was clear the VMWare was going to gut the company, and Broadcom only made that clearer.

It was once a great company... (Pivotal Labs)

Now it's toast.

I have never understood the VMWare/Pivotal thing, to the point where I assumed there must be two different companies named that for VMWare to have bought a company called Pivotal.

It was a different company until 2019. And they were doing great stuff, but it all went down after the acquisition.

Pivotal Labs was acquired by EMC back in the day. They bundled it with some cloud foundry work and created Pivotal. When Dell acquired EMC they also acquired a big share of Pivotal. Dell then decided to squeeze more blood from the VMWare stone and forced them to acquire Pivotal before selling the whole thing off to Broadcom.

Agreed, and I suspect part of what made it great is that it was being ignored. I love all the dubious new features it doesn't have, and the complex larger platform offering it isn't a part of.

Linear is the one I've settled on, it stays out of my way.

For now. Looking at the competition it's only a matter of time before it becomes bloated to justify valuations.

https://linear.app/

We've been on Linear for a couple years now and like it a lot.

As soon as the AI features start showing up in Linear, it's time to jump ship. You know for sure VCs are pushing for that in the weekly meeting.

If it takes the pressure off, then go ahead and add those features.

But carve it in immutable, legal stone that there will always be a classic (reddit style: old) version of the product that's feature-complete but maintained.

... my suspicion is there's actually legalese somewhere that mandates the continuity of old.reddit.com. Otherwise, I'm at a loss to explain its continued existence in light of aggressive app pushing.

That's true. They are maybe the only major player who went with that approach. I wonder if their users are that vocal?

it's been there for about a year. you can use plain text to search issues, and the slack bot will auto-create titles when you create issues from there.

Linear founder here.

We look at AI as capability similar to any other technology. Instead of jumping on the AI bandwagon or thinking AI is a feature, we look if there is opportunity to reduce friction or help the user well in the workflow they are doing. Today like the AI can inform if there is duplicate issues being reported or improve the titles you submit from Slack conversion.

A past job used Pivotal for several years until a new employee asked if we'd ever heard of Linear. I think we started the migration maybe a month later.

> bloated

This is like Excel - nobody needs more than 20% of all its features... but a different 20% for everyone. Project Management/Tracking needs can vary a lot between orgs or even people.

That's not really true: witness Jira boards which are really kanban boards replicated everywhere. Jira, by now, is mostly a database of issues with a terrible management interface that's only accessed through the "boards" features.

At least in the "agile" (actual or lookalike) software development.

We found https://www.shortcut.com less opinionated than Linear and a closer 1 for 1 to Pivotal. They're all getting a little bloated, wish one would dial it back vs keep adding (which feels like the inevitable future for Linear).

Out of curiousity, what do you dislike about spreadsheets/google docs? This has been my primary means of tracking progress historically. I've tended to find that all other mechanisms just add unecessary overhead.

Not the person to whom you're responding, but:

Collaborative/online spreadsheets can work. Carefully designed, with appropriate field constraints and filters and sort templates... especially for smaller lists or smaller groups, they can be OK.

A few areas where they break down though:

  - No attachments to stories (test cases, screenshots, etc)
  - No comments/history view or threaded discussions
  - Poor usability of notifications on @mention
  - Inflexible UI/data formatting (cells instead of layout)

I'll often start a project using a spreadsheet, because one big advantage is that you can edit several "stories" at once. So it's a good rough draft. Inevitably, the missing features become more important and I move the data over to a more appropriate tool.

Sometimes I keep the spreadsheet for internal stakeholder issue reporting. It's a business-familiar tool for gathering input, which then gets synced to the more purpose-built tool for action.

Pouring one out for Pivotal Tracker. This was an outstanding ticket tracking and project management system, way ahead of its time.

Back when I did contract software engineering, Pivotal Tracker made managing client relationships a breeze by giving the client perfect visibility into the impact of feature requests, and allowing them to make the tradeoffs that made sense for their business.

"Want to add this new feature, and do it right away? No problem, but as you can see, if I drag it into this week, as a 4-point task, it pushes everything else back by two days, which means we'll have to cut something else or change the launch date."

Great UI, great vibes, and was just a delight to use. Even as PT dies, its legacy lives on. Thank you, PT team!

RIP PT. I can't tell you how much this piece of software changed my life. Working at Pivotal (the very early days of Cloud Foundry), taught me so much about how to develop software and products. It taught me how to work closely with people (pair programming for the win!). How to iterate and pay attention to velocity. How to write stories. How to polish a turd over time. I use these skills every single day.

You will be missed old friend. Nothing else comes close.

> How to polish a turd over time.

You mean iterating and pivoting.

No, I mean taking a turd, which was the Cloud Foundry codebase that Pivotal inherited (aka purchased), and polishing it to be something that actually worked.

It is arguable if it was ever sufficiently polished, but at least we tried our best.

I heard this from other people that worked on Pivotal. Must have been a cool eng team.

Some of the best people I've ever worked with. Still friends with many of them to this day.

Same. Out of 15 shops I worked for this was absolutely different (2017-2018) and the only place I've seen pair programming and TDD done right. Once we managed to deploy first version of a trading product with no bugs at all.

When I tried to explain other people afterwards how to do this, they just shrugged, as if I told a fairy tale. I had a chance to demo it maybe a couple more times while migrating other systems, and very successfully (and with very low mental and emotional effort) - itemizing the tests cases first, building fakes, frequent commits, trunk-based development, small stories, incremental improvements.

But it's never been perceived as a designed success, they are typically so prejudiced that they saw it as a fluctuation in the monkey circus of software development they got used to.

Now I'm at the stage we need a support group for ex-alumnis.

Shortcut (https://www.shortcut.com/) is a solid alternative to Pivotal Tracker. I work as an Engineering Manager there and helped build an importer for Pivotal Tracker data into Shortcut (https://github.com/useshortcut/api-cookbook/tree/main/pivota...).

Shortcut as a product is team-oriented with solid GitHub/Gitlab/Bitbucket and Slack integrations.

Still feels like too many columns, too many states.

Pivotal Tracker - ice box, backlog, or current iteration.

I see companies in Trello Hell - well meaning, but often conflated, grey area states. There's like 10-15 columns on their boards.

It's a hot mess.

I worked on a tool more crowded than this and of late I’m coming around to the idea that these tools are all built for management which is why they get deployed. These drag and drop views aren’t that helpful for engineers. And they just make it easy for someone else to accidentally fuck up the status on your tasks.

The task list in Jira is good enough for finishing or marking one task as blocked and starting another. If anyone is using the interface like Tom Cruise in Minority Report, dragging things around at pace, it’s because people aren’t keeping their tasks updated and a tool can’t and probably shouldn’t try to fix that. You fix that by orienting the UI so devs benefit from using it, not by guilt tripping or lecturing.

I agree. People who like Pivotal Tracker (like me) for its focus and simplicity would not enjoy Clubhouse.

Woah wasn't this called Clubhouse at one point? I'm getting blast from the past! We used Clubhouse at Papa long time ago.

It was, and at that time it suddenly became much harder to do a web search on how to do anything in their UI! Turns out, Shortcut is not the most Google friendly name.

Are there any open source self-hostable tracking/project management tools that still have a committed team and forward momentum?

I used to self-host a Phabricator instance, which I liked a lot, but the upstream maintainer made the reasonable decision to step away.

My guess is there is not much of a niche for self-hosted solutions anymore. The GitHub Issues free tier covers most of the low-complexity use-cases, while higher-complexity use-cases are addressed by enterprise SaaS.

https://we.phorge.it/ is a community fork that appears pretty active.

I was also very fond of Phabricator (all though my team preferred GitHub style pull requests) but I haven't had a need for it recently, so I haven't tried phorge myself.

I've been using Plane (https://github.com/makeplane/plane), also available as a hosted solution (https://plane.so).

> Are there any open source self-hostable tracking/project management tools that still have a committed team and forward momentum?

Taiga.io?

> My guess is there is not much of a niche for self-hosted solutions anymore. The GitHub Issues free tier covers most of the low-complexity use-cases, while higher-complexity use-cases are addressed by enterprise SaaS.

Especially with the presence of free SaaSes such as Trello, and integrated project management in self-hosted GitLab, yeah.

Phabricator? OK, how about…

Redmine:

- https://www.redmine.org/projects/redmine/repository/svn/show...

- https://www.redmine.org/projects/redmine/wiki/Download

RequestTracker:

- https://github.com/bestpractical/rt

- https://github.com/bestpractical/rt/releases

A bit like Phabricator, these are almost frameworks that can do a ticketing UI.

// But really, probably something mentioned elsewhere in the thread, Taiga:

- https://community.taiga.io/t/taiga-30min-setup/170

This is sad to see. I haven't used PT in over a decade probably, but I used it heavily for 3-4 years before that. As a contrast to other "agile" tools, it was a breath of fresh air. So simple, everything was all on one screen, so easy to move things from state to state. My team loved it because they could just open it up in a window and leave it open all day, making changes as needed. I don't think I've ever seen anything since that came close to it.

I just logged in for the first time in years and found that I still had two side projects in there. Time to download them I guess.

I'm opening my Pivotal Tracker project from 2011... and I'm surprised at how good the UX is/was!!! Visually it looks old, but the UX I think is great:

Simplicity is reinforced with a great information density: lots, but not overwhelming. Current design trends make information density super low, forcing you to scroll a lot and spending much more energy/time just to be able to look at things.

When you need to "open" an item, you remain in the same screen (no modal, no context change): metadata, description, conversation. Nothing more!

In Linear I'm totally lost with projects, cycles, views, projects...

I'm stuck with Github Issues/Projects, but I miss Pivotal simplicity!!

I've just exported a 10MB Pivotal CSV...

Wish 37Signals would clone something like this and sell it via https://once.com/ (pay once, install and host yourself).

They won't because Basecamp has a board view.

We have to use Jira at my current workplace and it's so complicated. Pivotal Tracker, which I used at previous workplace, was so simple and focused. Sad to hear it's shutting down!

I am fascinated by how complex JIRA is. We evaluated it in 2008. It seemed fine enough.

Looking at it 16 years later, and… what is this nonsense? It’s so customizable that it’s loaded with footguns.

I had some thoughts on Jira: https://honeypot.net/2021/10/01/jira-is-a.html

TL;DR it's so completely customizable that it's more like a DIY project management toolkit. Pivotal and Linear have/had a more opinionated approach: "here's how you manage projects. Good luck and have fun!" Jira almost seems to push otherwise rational people to build the most baroque processes imaginable.

> Jira almost seems to push otherwise rational people to build the most baroque processes imaginable.

PM's gotta justify their jobs somehow.

I love a good PM. Trust me, you don't want to be responsible for all the reporting and status updates and all that they have to deal with daily.

It's just that I've never worked with someone I considered a good PM who loved Jira. The great ones wouldn't care if we did all the planning on papyrus because they were more concerned with getting things done than documenting them in excruciating detail.

it's the super customizable ones that end up adopted across large Enterprises. Flexible workflows I guess. eg Salesforce, Jira

I have a theory: Back in 1996 Bugzilla worked very well. It had been designed, and honed, by a bunch of senior developers who also wrote the bug management system. So lots of dog food eaten. iirc it was written in Perl.

Then, someone I believe decided to make a "Bugzilla in Java", because they didn't like Perl (reasonable).

But whoever that was didn't have the deep knowledge of how the thing was supposed to be used. Lacking that insight, they created a "Swiss Army Chainsaw", implementing simultaneously everything, and nothing.

Next, some MBAs got hold of the thing, and made everything 10X worse.

Meanwhile, Bugzilla is still the same and still the best software project management tool, if you know how it's intended to be used.

In fact, the name “Jira” is a reference to Bugzilla. Atlassian says:

https://confluence.atlassian.com/plugins/servlet/mobile?cont...

> We originally used Bugzilla for bug tracking and the developers in the office started calling it by the Japanese name for Godzilla, Gojira (the original black-and-white Japanese Godzilla films are also office favourites). As we developed our own bug tracker, and then it became an issue tracker, the name stuck, but the Go got dropped - hence JIRA.

Yes, _and_ having recently learned it and created my team's new board, the first thing I did (and you can to!) is disable all the extra features and issue types besides epices and issues. Kinda simplifies things.

I've never used Pivotal Tracker, but at my dayjob we're moving from Jira to Azure DevOps (ADO) - due to supposedly high Jira license costs...Now, historically i have been quite critical of Jira - because its always felt so complicated for me. But, now having lived in ADO for about 6 months, i hate it! I hate ADO with a passion! At first, i thought that its simplicity was great...and then started running into loads of walls - even for simple things. I never thought i'd live to see the day when i wish to go back to Jira. Then again, as others here have noted, maybe the complexity of Jira is not necessarily native, and simply a fact that jira *allows* for way too much complexity, but that, it can be made more sane/sensible (such as by shutting off a bunch of customization, etc.). And, who knows, maybe the crappy over-simpleness of ADO that i'm painfully living through might also be a thing that was poorly customized at my dayjob...But regardless, i guess right now I *prefer* the pain of Jira vs the pain of ADO. Clearly, there must be other products that sit in the happy Goldi locks middle (not as complex as Jira, but not as simplistic as ADO) that help teams actually get work done, and that are not so costly, etc.!

Their site still has a COVID-era banner about "unusual times." Talk about a neglected product.

COVID is still a thing, and we are indeed in strange times.

When does "strange" become "normal"?

Maybe after the upcoming election? But I'm sure the next election will also make things weird.

Pivotal Tracker was the first time I saw a digital kanban board where the workflow was represented as a series of columns you dragged items through. Since then, its become popular paradigm for pretty much every popular project management software UI around.

I always wondered, did Pivotal Tracker invent this paradigm? They were surely using it before any of the big players utilized it.

My first tech job was for a small IT consulting company that specialized in open source solutions in the early 2000's. The owner was basically the sales and overall strategy guy, I did consulting and implementations with clients, and most everyone else specialized in either their own low-level tech or business stuff.

At our height, the owner started bringing in more projects than our current workflow could handle. Customers started getting angry because their projects would slip through the cracks and get delayed if they weren't calling us up weekly to nag us for status. I sort of became the project manager by default because I touched most of the projects in some way and I was the go-to guy when someone had a question about the status of a project. I wasn't really happy about this because I liked doing tech stuff more than I liked managing projects.

In an attempt to preserve my sanity and get back to logging billable hours, I grabbed a deck of blank index cards and wrote down the company name, project name, status and for each project we had. (I didn't like spreadsheets at the time and this was faster than writing code.) That way, I didn't have to actively remember the status of every project. When needed or when asked, I could just grab the card and look. Once a week or so, I would update the status of each project on the card.

Not long after, I got to noticing that there was really only four (or five, I don't recall) states that any project could be in and decided to stop writing them on the cards. Instead I placed the cards in dedicated piles that represented the project's status and moved them around as needed. That worked well. Eventually, I thought it would good if everyone on the team could see the projects and their status as well, so I grabbed an old whiteboard, hung it on the wall behind me, drew a column for each status, and taped all the cards into the column corresponding to their status. This was a BIG improvement. I stopped wasting an hour every morning just going over project status with the boss and other employees. Everyone could just walk over to the area near my desk and look at the wall behind me. (It was an open-plan office before those were "cool.") Others could move the cards between columns themselves. When a client called demanding an update, I could just glance behind me.

A few jobs later, I took a compulsory three-day seminar on Agile and saw that they called this thing a Kanban board.

No, Pivotal Tracker did not invent this paradigm. For background, I started working around 2005.

Before tools like Tracker or JIRA, people who were doing agile development did everything with physical index cards. There was a lot of controversy even about digitizing those workflows back in the day - "we lose human connection and conversation by putting it in the machine!" Nobody has those conversations anymore as far as I'm aware.

Like others have mentioned on this thread, the true innovation of Tracker was to have a single view where stories are ordered vertically in a single column and grouped by status. This really changes the conversation around what is top priority. Everything can be urgent and have a high level of priority, but if you put something at the top, something else must shift down in compensation. No more doing that thing where there are five number one priorities at the same time.

The Agile view in Jira actually owes some inspiration to Tracker, if you can believe it. I know because I was there. I was a client on a Pivotal Labs project way back in the day, back when Tracker was still not publicly available, but only available to clients of Pivotal Labs. Our PM loved Tracker and wanted to use it but knew we could not get approval for it back home, all other teams were on JIRA. So our PM found a JIRA plugin called Greenhopper, tracked down the developer, and fed this person feedback to try and turn Greenhopper into the most Tracker-like thing possible. Greenhopper eventually got absorbed into Atlassian and turned into what is today known as Jira Agile.

Tracker felt like such an amazing breath of fresh air and forward looking technology at the time when it came out. Tracker used Ruby on Rails and did sexy AJAX stuff on the frontend (big wow factor back then, this was the age of IE6).

I loved Tracker for many years. I could sing its praises all day long. That said, the people who worked on the product had some philosophical things that got in the way of the product evolving. Reasonably, they did not want to turn into a huge enterprise tracking tool. Problem was, there were never any more features built into Tracker that really gave a good view for people who were higher level than the daily boots on the ground folks. So no good visualizations or features for projects where multiple teams must execute in tandem, and there are complex interdependencies between the teams. So while Tracker was awesome for the folks on the dev team, it wasn't very helpful for people in middle or upper management who needed birds-eye visibility easily and at a glance.

So although I am sad to see this announcement in a way I'm quite hopeful. There are so many people who love this tool and will miss it, now there's no excuse for them not to go build something better!

Noooo I use tracker for everything. There's no project management software like it in simplicity and function. You'll be missed

You should try out Taiga.io. Super simple (possibly TOO simple), light-weight, open-source and self-hostable.

I do like the approach Basecamp took to Kanban ("Card Table") - very very simple and clean (https://basecamp.com/features/card-table). We moved off of Basecamp but we found it super effective when we were a smaller team.

There are many alternatives:

- https://www.easyredmine.com/

- https://www.openproject.org/

- https://taiga.io/

- https://www.stackfield.com/

- https://zenkit.com/en/

Anybody know any other PM tools that do the auto sprint planning like Tracker does?

Linear

Looks like it, that's new! I tried Linear quite some time ago and it didn't "stick", I'll have to give it another shot.

Thanks for the tip!

Linear is the best project management for software I've ever used, highly recommend. They've added many many amazing features this year... Incredible team over there that are just a joy to work with.

I really like it too but am worried it will go the way of other tools and need to start appealing to enterprise to expand.

+1. Linear is a great PM tool, maybe even the best. What makes it awesome is their support team. I’ve been in touch with them a handful of times over the past ~5 years, and each time, they’ve been excellent — fast response times, with genuine and tech savvy people on the other side.

I’m glad to hear! :)

Linear is starting to hit against the boundary of enterprise requirements: tracking and compliance where as a product company needs to ship great products. The VC returns is in the former so it will be interesting to see which path they choose.

Linear founder here.

We aim to build the product in a way that it works well for smaller/early stage teams as well as all the way to the enterprise. So I think lot of the “enterprise” stuff will be optional.

That's too bad. At one of my companies they were using Trello for all engineering development which I found just too casual of an approach. Jira would have been overkill.

Pivotal provided a nice middle ground and was so easy to use with just the right amount of customization and power user functionality.

But I always felt like there was a small group of users and it just never got a foothold in companies.

I find Shortcut to be a nice middle-ground between JIRA and Trello.

I signed up for Pivotal Tracker a month ago, after a ten-year gap. I loved the simplicity then, and I love it even more now. I'm saying this after using multiple different project management/Agile management apps.

I still use all the terminologies I learnt from PT — Icebox, backlog, current — across other project management apps.

Sad, and you will be missed.

Shortcut.com has it's an importer tool from Pivotal. Give it a go! https://help.shortcut.com/hc/en-us/articles/205965835-Import...

Checkout Shortcut.com! They have an import tool from Pivotal Tracker.

https://help.shortcut.com/hc/en-us/articles/205965835-Import...

We love PivotalTracker so much, that we want to build alternative that feels like home. We are looking for support to make this happen. Can you check out https://litetracker.app

p.s. Yes, we tried all of the alternatives and none works for us.

This has been coming for a while. I feel bad for anyone still building on anything Tanzu these days. I expect we will see a similar announcement about some or all of those products in the coming years. It’s gotta feel stressful to those teams relying on these products.

I briefly worked on the Tracker team until VMWare bought Pivotal. One of the best teams that I have ever worked on that truly cared about the product they were building.

While pairing could be exhausting, it built a really incredible culture there that will be hard to recreate.

RIP

Can they open source it?

It should be a legal obligation that, passed a certain threshold of time and user base, you are required to do so.

There should be a very high standard for "the government can force me to do [something]" and it shouldn't be thrown around as casually as, one of a thousand enterprise CRUD apps went away.

Government doesn't need to force you, they can just not grant you copyright protection if you don't escrow your code for eventual release.

It should be a requirement for receiving copyrigt protection in the first place. The whole point was that things end up in the commons.

Respectfully, i am not sure that i agree with that. I think if it were allowed to slip into, say, public domain, then, yes, i agree.

HOWEVER, on a slight tanget from that point...If this company and its software have ever received any sort of taxpayer funds, then my opinion is that from the beginning, such software should have been open sourced. Publicly-paid software should be publicly available. Of course, said business has every right to earn profits from providing the service such as hosting said software for convenience for customers. But, every citizen who paid taxes has a right to see (and access!) all the code...well, that's my belief anyway. ;-)

I've heard that they're actually considering it!

Truly the end of an era.

man, what would I give to have Atlassian shut down - so much frustration, anger, productivity lost and just absolute misery caused by that terrible company and their horrible products

I actually liked using Tracker.

Atlassian's primary sin is listening to PMs for features.

As a subset of users, they seem to want the flexibility of Excel, except it also has the specific workflow they want out of the box (which is different for every PM).

Every product that's chased that rabbit down the hole has ended up with something customizable enough that (a) users need training to actually use it & (b) nobody is ever trained on it.

I'm sure Jira is great... if I and everyone else at the company went to a two-week training course on configuring and using it. But none of those people, nor I, am ever going to do that.

Tl;dr - project management/tracker tools should have a complexity feature cap, defined by what a reasonable person can intuit in the course of normal use over a month.

I would rather just use an actual spreadsheet for issue tracking than Jira.

We lost our CTO recently, and he was also the "jira admin" (ie. the only person who knows how the hell to do anything with jira) and it's just been a clusterf*ck ever since.

Excel-as-a-benchmark is a powerful thought argument.

If something can't be significantly better than Excel, then product specs probably need refining.

It's not that Excel is amazing or perfect in any one thing, but it is a pretty amazing blend of simplicity, flexibility, out of the box features, programmability, and presentation.

this dovetails into my test for whether i’m looking at a good startup idea or not… if existing solutions are all complicated spreadsheets, there’s both a potential market of users, and the problem is complex enough to warrant some code to manage it.

ETA: obviously not all good startup ideas fit into that thesis, just the ones i tend to enjoy working on.

It's a good test, but also a trap. Because the relevant follow-on question is "Is it possible to design a single solution that will please most of these people?"

Sometimes, the nature of the problem makes flexibility irreducible.

you’re absolutely right! that’s where the art and science of product comes in, knowing what’s possible and whether you can cobble an addressable market by choosing which subset of stakeholders to please.

Devin from Shortcut here, happy to walk anyone through our API importer capabilities and provide a couple months of our Business plan for evaluation. Details on the importer capabilities: https://www.shortcut.com/blog/importing-from-pivotal-tracker...

Shortcut is a good alternative to Pivotal (https://www.shortcut.com/)

Its really sad to see the best project management tool ever created fade away. Its not just the best and most intuitive way to do delivery predictions and team capacity planning but also somehow managed to reach peak interface. As development slowed down it felt more like a japanese tea cup that just reached perfection. (except for github integration)

would love to make a clone.

No way!! The best tool ever. Jira and its ilk are designed around executives “product managers” who want to micromanage every damned thing.

If anyone is still lurking in this thread - how realistic would it be to try to buy Pivotal Tracker back from Broadcom?

Is the possible purchase cost below the minimum that Broadcom's legal department even accepts to look at? (i.e. they don't get involved with "small" sub-10M deals..?)

http://www.centralcm42.com

https://github.com/Codeminer42/cm42-central

> An agile project planning tool and Pivotal Tracker drop-in replacement

I will really miss Pivotal. Looks like my org will shift to Jira. People talk a lot about how Jira is so customizable to the point of it being problematic. But would it be possible to customize it to work somewhat like Pivotal, I wonder?

Like others have mentioned, if you like Pivotal, check out Linear first.

If you end up on Jira, once you get it configured, put the admin password in a bottle and throw it into the ocean. Do not let anyone say "you know, if we made this one little change to our workflow...", because once that dam breaks all hope is lost.

I always loved Tracker and it sucks it got sold and resold until they shut it down like this. I am using Linear but it doesn't have simplicity of Tracker tbh.

Maybe Tracker belongs in different time that we will not go back to, who knows.

Only 7 months to get their data out and migrated to new provider, oof, thats rough.

Ouch. VMware could at least open source it if it's no longer available.

They're not migrating users to another VMware company product?

VMware can't sell Pivotal Tracker to some company that will keep it going longer (and perhaps try to migrate customers to their own product)?

Since VMware sold to Broadcom in 2023, they've been cutting jobs and increasing prices to squeeze every bit of profitability possible out of their remaining customers. I'm actually kind of surprised they aren't offering support past April 30 2025 end-of-life date for 50x the current pricing.

Oh, not to worry, they will :)

Actually I think that was the original plan: https://news.ycombinator.com/item?id=39607630 Apparently not enough interest to justify continuing.

Broadcom is in my bad-vendor list due to the handling of VMware.

Most of my job as a developer now is wading through bureaucracy that other people created (e.g., figuring out a poorly-designed, poorly-implemented, and poorly-communicated third-party API that often would be easier to do myself from scratch).

When I do hold my nose and wade through someone else's bureaucracy, and become dependent upon it, it had better not be pulled out from under me by some coked-up MBA who doesn't care what customers think of them.

Can someone explain to me how Broadcom's plan is supposed to be profitable in the long term?

I don't get it. You buy a company, then deliberately destroy it. How is that profitable? I get that there are tax benefits to being able to show massive losses, but certainly the net at the end is still a loss.

I don't think they're aiming to have massive losses. VMWare had $13 billion in revenue and $1.5 billion profit, and it seems their aim is to cut way back on costs by laying off 40% of engineers etc while maintaining what revenue they can, and reap the unrealized profit potential there by giving up R&D, future growth in the VMWare product categories.

The end of an era. Good Pivotal Labs, was nice working there.

Problem with these trackers is that they are by design super opinionated on how your work flow is gonna be once you get past simple reminders type tracking

Just came to say, I still think this is the best balance between the many factors of running a dev team. I keep trying to recreate it in every tool I use.

I remember using this around 10 years ago and liking it quite a lot, especially compared to Redmine we replaced it with.

What's the best, open source equivalent?

I remember their (pivotal) culture was very unique. Maybe the developers have tired out of mandatory pairing

I recall the mandatory pairing as quite popular among some devs during that era. I wonder if anyone is actually still working in that manner.

Yeah. Now they are pairing with a chatbot.

I do alot of my work after close of business, I don’t do well in companies that require collaboration to get tasks done

I’ll pass all team player marks and metrics, but if there’s too much custom tooling, distributed knowledge and gatekeepers, my performance will suffer more than those that pair all day

Funny story, I work out of a small part of Accenture and was just today explaining to a client that this is how we work (pairing, TDD, etc.). Way back in 2018 or so we had a partnership with Pivotal and they taught us a bunch of their ways of working. It's been a challenge to maintain, especially through Covid, but a lot of the core ideas and practices are still alive. It doesn't work on every project, but man when it does it's a very nice way to do software.

When the flow between the pair hits, it’s a beautiful thing.

I work at what used to be Pivotal, now Broadcom via VMware, and do pair programming every day. It was a bit of an adjustment, and I do sometimes miss solo dev work, but pairing does have some real benefits. It is really nice to have another set of eyes to catch mistakes you miss, and it's fantastic for spreading knowledge and onboarding new developers.

I never worked at Pivotal but did work in a 100% pairing cultural (it wasn’t forced but our team did it for three years) and I desperately miss it. It’s so hard to find companies that do it.

I worked with several Pivotal teams, and also really miss it.

I've never been as productive or had that much fun at work.

> I've never been as productive or had that much fun at work.

This was my experience as well.

I miss it every time I review a behemoth PR, or another engineer proposes a giant design change in a PR.

Those discussions need to happen earlier

I’ve been asked to review massive PRs that were produced by a pair plenty of times.

People have very different views on this and there are no rules, but in my view one of the major benefits of pairing all the time is NOT doing code review.

Thoughtworks is exclusively a pair programming org. I went through a full interview process with them and ultimately declined the offer because it didn't feel like the juice was worth the squeeze on all the travel, strict pairing, and low salary.

Worked at CoreLogic Labs, which was 100% influenced by The Pivotal Way. It would leave me utterly tired at the end of the day from the pairing, but what a way to reduce some silos and increase productivity.

1 computer, 2 mice, and 2 keyboards. Had a few mice wars that got frustrating at times, but still loved it. Had my best manager there of my career — Guss.

Quite sad that they’re shutting down Tracker as it’s just such a good tool compared to others.

I remember starting at Pivotal and being shocked by the two mice, two keyboards (and two displays, mirrored) setup. At the previous XP shops i had worked at, we had one mouse, one keyboard, and one display (comprising two monitors) - sharing the physical peripherals made sharing and transferring responsibility completely natural. It seemed bizarre to me to duplicate them, introduce what you call mouse wars, and make it impossible to point at something on the screen. But of course, everyone at Pivotal insisted that theirs was the only way to do it!

Reminds me of the BitBucket “spooning” video. https://www.youtube.com/watch?v=8wUOUmeulNs

I worked at Pivotal (2017-2018) and I'll say pairing culture is not for everyone but it was a great experience for me. Much of the experience is dependent on finding someone that is at your "wavelength". It provided good work structure and reduced knowledge silo'ing.

I had good experience with it, fwiw.

Surprised to see this. Still one of my favorite kanban implementations. Mostly just gets out of your way.

I got to work on Pivotal Tracker in 2006 during it's first rewrite. Fun project.

I could have called this years ago when I found out they exclusively use and enforce pair programming in-house

https://tanzu.vmware.com/content/blog/what-s-the-best-way-to...

> I could have called this years ago when I found out they exclusively use and enforce pair programming in-house

No, you could not have.

The environment that birthed Pivotal Tracker had the same culture, and the death of PT is a consequence of multiple profitable acquisitions, eventually into a multinational semiconductor corp that has no use for a small SaaS devtools product.

You could probably have called it based on the acquisition chain though. Many of us have been hoping to be surprised. Our luck has run out.

I was an engineer on Tracker from 2013 to 2020. I’m sad to see it go.

If it's really that valuable, someone will offer to buy it.

Hate it when the VMware Tanzu division does that

Pouring one out. I remember using Pivotal Tracker back when working in a Ruby on Rails shop and enjoying directness and how optioned it was of it.

Then several years later, after working in large Silicon Valley tech companies, and seeing how they run with Jira, I decided to start https://linear.app

So much team's time and effort went in to configuring their tools instead of actually working on things. We do more than PT did, but aim to keep the experience straightforward and focused, regardless of the size of your team or company.

Surprised nobody has dropped a monday.com advertisement into this thread yet ;)

"Yes, that Pivotal."

These guys were pioneers who set forth a lot of the patterns used in other PM software (Did they invent "Velocity"?). I hated Pivotal in the early days, but after a couple years on the job I learned to really love it especially as the newer flimsier sprint planning tools were popping up in the early web 2 days.

Only Trello really "beat it" fairly - Jira was always top-down forced, and Asana only won with designers because it was pretty while Pivotal was more tactical (not to mention they clung to skeuomorphic UI a little too long). The rest is history.

I guess we can say Pivotal was quite pivotal in the AGILE/sprint/PM software race. RIP

We were doing “velocity” at a startup using a rack of index cards. Software is not strictly necessary when everyone is in the same room.

PT's concept of velocity isn't just tracking a number. It is tracking what work will get done within a period of time based on the average amount of work done previously. It allowed PM's to actually estimate when a feature would be completed and how adding or removing stories (or people!) would impact future feature deadlines. Initial velocity was meaningless and only developed over time as an average value of a team of people working together, taking into account things like vacations and sick days. None of this could be done realtime with a rack of index cards as it was something that happened over many weeks.

Yes, that’s basically how we did it. Though not formally accounting for vacation days; there were four of us and we didn’t have people coming and going much. We only did it once a week during the retrospective. It’s not hard to add up story points for the week and remember what you did in previous weeks. You could enter it into a spreadsheet if you want to get fancy.

The concept comes from Extreme Programming. Software implementations came later. I think Pivotal Tracker does something useful, but you need a larger team for it to matter.

Here are some photographs of the team room:

https://williampietri.com/writing/2004/teamroom/

> I think Pivotal Tracker does something useful, but you need a larger team for it to matter.

My buddy and I built what ended up being an $80m/yr gross revenue business entirely using PT for ourselves. We shipped a MVP exactly to the week we predicted. It helped that we both worked at Pivotal and knew exactly how to use PT correctly.

You certainly were early with the process and I applaud you for that! PT wasn't released until 2008.

That concept of velocity is in the original Extreme Programming practice, which predates Pivotal, and it was indeed done with racks of index cards.

It's explained pretty clearly in the first edition of Extreme Programming Explained, but i can't find a copy of that online right now. The second edition was absolutely ruined for some reason, but still contains a rough description of it:

> Whichever units you use, hours or points, you will need to deal with the situation where actual results don't match the plan. [...] If you are estimating in points, modify the budget for subsequent cycles. A simple way to do this, dubbed "yesterday's weather" by Martin Fowler, is to plan in any given week for exactly as much work as you actually accomplished in the previous week.

Tracker uses some kind of rolling average rather than just last week's number, but it's the same idea.

I never implied that PT invented the concept. I was just explaining the concept in relation to PT.

Doing what PT does, with index cards, would have been a nightmare on any sufficiently large project.

IMO all of these todo list apps are the same - no moat and not useful enough to be critical for anyone or anything.

No idea how Asana is still valued at $3B it's literally just notepad with checkboxes.

Pivotal is the company whose CEO went to Burning Man and wrote a 100% unironic blog post about how it changed his life right?

How many companies have you sold?

And who are we to judge what changes someone's life?

who are we to judge what someone finds funny?

Really? Do you have a link to the blog post?

Reply on news.ycombinator.com