in reply to Re: How not to implement updaters
in thread How not to implement updaters

The manufacturer announced the transition from on-premise to the cloud more than a year ago. Why is there no startup producing a non-cloud replacement? They'd make a fortune.

It's a closed source product, so you can't simply fork it and keep maintaining a local-server version. (That would be great.)

So that startup would need to re-invent the wheel AND get a sufficient number of users out of the manufacturer's cloud lock-in. That would at least require a very smooth migration procedure and very attractive pricing. That startup would need a lot of very competent and very efficient developers plus a lot of money to acomplish that.

Speaking of pricing, the manufacturer used tactics that you would expect from a drug dealer, and they worked much too well: "Hey, want a bugtracker? It's almost free, just a few bucks for the first few users. And a few bucks for the requirement tracker for the first few users. And the same for the test tracker." One more licensed user, and the price explodes. To be fair, the next level after "a few users" is/was "a big company".

My boss did some math a few years ago, and found that the "few users" license should be sufficient. It just barely fits now. And we are probably not the only ones who relly wanted a license level between "a few users" and "big company".


The cloud. For us, it does not look like a pretty fluffy cloud (like on the WinXP default desktop), it's more like a thunderstorm coming closer.

We did a lot of paperwork for our quality management (which we must do to legally develop our products) to use exactly this tracking software, and all of our active projects are tracked in that software. Porting that to any other software does not only require a smooth migration, but we also would need to redo the paper work.

We will need to upgrade, to almost the latest version. Requirement and test tracking aren't supported by the newest versions, newer requirement tracking versions are only available in the cloud, test tracking seems to be dead.

So we will need to migrate our data. Issues, Requirements, and Tests, either to the not-so-well managed cloud, or to some other software. It does not have to be done right now, but probably within the next two years.

I'm sick and tired of the software, and luckily I'm not the only one. It is a resource hog, it is closed source, updates are a nightmare, the web interface can't handle big screens very well, it absolutely can't handle using more than one browser window, and there are many other annoyances. We want to get away from it, probably to some open source (and ideally free-as-in-beer) software, or at least a software that has resonable, non-drug-dealer license steps and a working updater.

Also, while the software can link issues, requirements, and tests very tightly, we actually do not use that feature very much. Ideally, we would, but in reality, there is the issues world of a project, and the requirements and tests world of a project. Both are pretty much isolated, and our actual workflow works fine this way. So, we already discussed using two different systems for the two worlds, one pure bugtracker (e.g. redmine, bugzilla, ...), and one that tracks requirements and tests. Of course, switching to another software requires a lot of paperwork (plus migration tools).

We (the developers and our boss) will have some very interesting discussions in the future.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)