
Show HN: Ship – A fast, native issue tracker for software projects - kogir
https://www.realartists.com/blog/ship-it.html
======
swanson
I kind of wish that software issue trackers/ALM/SCM/whatever-the-fuck-its-
called-today would be a bit more opinionated and enforce some set of
practices. I think some people are looking to these tools for help building an
effective software workflow and are left with a configurable product that
_can_ work great -- if you've run projects effectively before. But if you
haven't it turns into a nightmare.

I know that workflow, work item types, how to transition between states is
kind of a deeply personal thing -- but often I wish I could just eliminate the
mental overhead of trying to figure out how this project, manager, and team
are using Jira/Rally/TFS/Trello/Pivotal and what state I need to put something
at what time and which fields need to filled out and if we are using tags and
why adding this critical bug to the current sprint is giving me a big scary
warning and are we calling this a feature or a story or an epic or an
enhancement or a task or a subtask and if I want to be looking at what this
tool is calling a burndown chart or if its really the milestone progress chart
in this project and what was that filter you used to see bugs that were open
and also defined because I'm not seeing the bug that my customer is asking
about and are we supposed to put new information as a comment or in the
description or is it a new linked issue or a new child task or a new child bug
or a link to the integrated wiki page...

(maybe I'm just the only one with these scars...)

~~~
asfakeaccount
I find that Pivotal is pretty opinionated with the workflow you use.
Specifically, it is meant for an agile process that is exactly that Pivotal
(the consulting group) uses to develop their client products.

~~~
jacques_chester
Some nitpicks:

* Pivotal _Tracker_ is the SaaS software you're thinking of.

* Pivotal _Labs_ is the agile and lean engineering/design/product/data science consultancy, from which Pivotal Tracker first emerged as a product.

* _Pivotal_ is the parent company formed from Pivotal Labs and other products (notably Cloud Foundry, Spring, Greenplum, Gemfire) several years ago.

Disclaimer: I'm work at Pivotal Labs.

~~~
aptwebapps
Yeah, Googled and ended up on the main site. Thought they were doing a
_really_ bad job of explaining their software for a bit.

~~~
jacques_chester
Calling Tracker "Pivotal" is pretty common.

My first thought is we should add a "did you mean Tracker?" link somewhere,
but that's got problems too. We work on a _lot_ of software.

------
kogir
Hey everyone!

James and I made Ship because we were frustrated with other tools we've had to
use. It's focused on developer productivity and meant to be used frequently
without wasting your time.

But seriously, we'd love feedback, both good and bad.

~~~
cjbprime
Have you considered using a source code repo as the store for issues? So that
"git pull" syncs issues too, issues can exist on (to describe) branches, etc?

~~~
TheTon
(james here)

There are a few tools that do this already. I think it's an interesting
approach, and probably makes sense for some people.

However, I feel like tying issues to closely to the code can be problematic.
For example, for the product Ship itself there are multiple repositories,
there's the server, the client, the web site, and a few libraries that we
built along the way and open sourced.

We want to be able to file issues on our product without having to first
determine in which repo the problem actually resides. We also want to be able
to file umbrella issues or features that require us to make cross cutting code
changes across multiple repositories.

~~~
zokier
I imagine that sort of issues would (mostly) be solved by a monorepo approach.
Of course that is also drastically different in many other ways too.

~~~
CodyReichert
That was my thought too. It sounds like having an issue tracker tightly
coupled with the code/repo structure would be extremely useful in monorepo's.

The problem might not be that it's hard to figure out which issue a repo would
belong too, but rather, having multiple (separate) repositories that have
things in common.

------
gregmac
One of the great features of a web-based bug tracker is that I can paste
ticket links in various places, which people can view with a single click.

On top of that, it's yet another app to be installed and kept up to date,
which everyone on your team has to independently do. If it auto-updates,
presumably one person updating will update the database and then require
everyone else to upgrade to continue use? I can't tell you how annoyed I'd be
if it did that right after I finished entering info for a new ticket..

I appreciate the feature set and motivations from that perspective, but I have
trouble with the native app part. I'm a very heavy app user though; Aside from
my actual IDE, git, and the executable code I am actually writing (generally
web apps or background daemons), everything I do is web-based: Email, chat,
docs, bug tracker, wiki, build server, repository management, notes, news,
music...

~~~
kogir
It's possible you've not experienced the problems that we have with web based
issue trackers. That's ok. Ship may not be the right tool for you.

As for all-at-once upgrades, so far it's not been an issue. The client ignores
things it doesn't understand and we've kept the server backwards compatible
for the last 7 months. We expect to be able to continue to do so.

~~~
sulam
I actually love the native part, fwiw. I've often thought that a native JIRA
client could be way easier to use than their web interface. Of course they
could also just invest in making their web interface much better, but native
expectations are naturally very high, and a lot of the horrible UX practices
we accept on the web wouldn't fly in a native environment. Essentially it
would have no choice but to be better.

~~~
andybak
> a lot of the horrible UX practices we accept on the web wouldn't fly in a
> native environment.

I'm interested by this statement. I like to think I just web and native apps
by the same standards. I've seen horrible UX in both - and great UX in both. I
currently lean towards favouring web apps based purely on my feeling that I
tend to get a better UI on average.

~~~
sulam
Together we obviously represent a pretty small sample, but I'm curious what OS
you use? One of the reasons I like MacOS is because the apps are typically
better designed than what I got when I used Windows or Linux as my desktop
(don't get me started on Linux UIs).

Don't get me wrong, I've seen some bad app UIs on the Mac -- even from Apple.
The old skeuomorphic days are coming back to me as I type this and I'm still
sad for them. :)

------
condescendence
iOS/OSX only? Meh. The real need is on every platform you haven't yet
developed for. At my work right now we use TFS built in tracking tools. I
can't even begin to described how annoying it is to work with that system.
There are no tools right now that have a built-in workflow and are minimal for
windows/linux. There's tons of bug/tracking systems but they tend to take the
approach of giving you tons of features and allowing you to make your own
workflow which ends up creating a big mess if people get lazy with filing
issues/tickets.

I'm sorry I know its a good first step, but those who need minimal issue
tracking and such are probably on a windows/linux platform where current
solutions are bloated and maybe even too feature filled.

Then again this is only my 2¢

------
dangoor
This reminds me a bit of Bee[1] which puts a native Mac interface on top of
existing issue trackers (GitHub, JIRA, FogBugz). On the one hand, Bee's
approach seems like a win in the short term because people don't have to
switch where there data lives or buy in to an off-premise service if that's
not what they want. Longer-term, though, the data model of the existing
systems could prove to be limiting if you've got good ideas for how to change
the approach here.

Issue tracking "at scale" is hard for the same reason that a lot of software
becomes complicated: when applied to the real world, new workflow needs and
such pop up frequently. As an example: security issues that may need to have a
restricted audience for a time. The release model for web-based software is
different from that of desktop or mobile software.

There's plenty of room to make this better! Good luck in finding a winning
path forward!

[1]: [http://www.neat.io/bee/](http://www.neat.io/bee/)

------
nathas
Looks neat. It's a bummer that it's Mac-only

~~~
kogir
We're planning to support the web and other native platforms. I use Windows.

Which platform do you prefer?

~~~
onetwotree
Linux please. If you're going to target the web, you might as well build a
desktop app with electron[1].

[1] [http://electron.atom.io/](http://electron.atom.io/)

~~~
bifrost
Looks like electron could work with FreeBSD as well, so I'd probably give a +1
to that!

------
mwcampbell
Looks like the Mac client is written in ObjC, judging by the small size of the
binary and the lack of any recognizable language runtime libraries. Is that
correct? If so, I guess you'll have to write a new client from scratch for
other platforms.

------
tokenizerrr
Looks nice. Also looks utterly unusable unless you can guarantee that everyone
you work with runs a Mac, which is not an option.

------
vbezhenar
I like native part, I like offline support (sometimes have to work without
Internet).

I don't like cloud nature (if I understood it correctly, I can't host my own
server) and it's probably not open-source which I don't like too (would be too
hard to make non-Windows server).

Overall it's a very interesting approach and I'll consider using it. Thanks
for making it.

------
schnevets
It looks great - and extremely tempting since I am currently going through QA
hell with a project, but I cannot tell from your website whether or not this
will stay a free product.

Do you or your partner have a plan to commercialize the software? Add premium
features? Or is this a side-project whose future is still being decided?

~~~
kogir
Pricing will be comparable with similar tools - probably on a per-seat basis,
but we'll do something special for early adopters.

It will always be possible to export all your data. We have that now, it's
just not exposed yet. Here's an example of the demo database:
[https://www.dropbox.com/s/ujix7vch7ramlmx/data.json?dl=0](https://www.dropbox.com/s/ujix7vch7ramlmx/data.json?dl=0)

------
Zash
We in the Prosody project were using Google Code and the project leader really
liked their issue tracker. When the shutdown was announced, we looked around
but found nothing that met our needs, so we ended up writing our own. I'm
personally quite pleased with the result:
[https://prosody.im/issues](https://prosody.im/issues)

[https://prosody.im/issues/static/readme.html](https://prosody.im/issues/static/readme.html)
[https://hg.prosody.im/issue-tracker/](https://hg.prosody.im/issue-tracker/)

Also see
[https://prosody.im/issues/issue/2](https://prosody.im/issues/issue/2) ;)

~~~
lemming
That actually looks very nice, thanks!

------
GordyMD
I just downloaded the Mac OS X version to try it out and upon clicking 'Demo
Mode' I am presenting with the next screen which is mostly blank (Screenshot:
[http://i.imgur.com/evyyF5v.png](http://i.imgur.com/evyyF5v.png)).

~~~
kogir
Thanks for letting us know!

That's a bummer. Sadly, I don't have any guesses as to why. I'm happy to help
debug if you want: nick@realartists.com, but understand if you don't want to
spend any more time on it.

~~~
sharp11
No no no.... No need to apologize! Just chase the bug. This looks awesome for
a V1! Kudos to you guys.

------
codemac
This makes me reminisce, we had lots of bug trackers that were close to having
these kinds of features when git was first hitting in the mid-ish 2000's.

My favorite was Simple Defects:
[http://syncwith.us/sd/](http://syncwith.us/sd/)

------
clay_to_n
General question about issue trackers in general:

How do people usually integrate these with other project management tools,
like Jira or Trello? Some of the issues shown on the site seem like what I
would call features as opposed to bugs. Is it a different use case? Does it
work to have software "features" in Jira or Trello or similar and then use an
issue tracker like Ship for just the bugs?

I used to use a system of filing bugs as GitHub issues and then moving them
into Trello when they've been scoped and prioritized and are ready to work on
- but lately I've just been putting them straight into Trello. Any insight on
workflows for combining software like this with Trello or Jira would be
appreciated!

~~~
dragonwriter
> Some of the issues shown on the site seem like what I would call features as
> opposed to bugs. Is it a different use case? Does it work to have software
> "features" in Jira or Trello or similar and then use an issue tracker like
> Ship for just the bugs?

"Features" and "bugs" are essentially the same thing: differences between the
current and desired state of a piece of software.

Tracking them in separate tools seems to be a bad idea.

~~~
clay_to_n
That makes sense. My next question then would be: Can you use Ship or some
other issue tracker to manage the software lifecycle reasonably? Planning for
a sprint or release, development, code review, QA, etc. I'm used to having
these as columns in Trello or Jira - is the alternative to do them as labels
or similar? Or would you use some other tool for them?

------
awaxman11
After looking through the documentation it doesn't seem like the following
features exist. Would love to know if I'm missing something, or if not the
thought process behind excluding these features:

1) Ability to prioritize problems on a more granular level than the priority
type. This would help people prioritize which problems they want to work on
next in a kanban type format

2) Story points or the ability to estimate the approximate size of the task

~~~
kogir
We don't personally like agile.

We would like to add the ability to order problems - both a personal work
order queue, like "I'm doing this, then that, etc." and globally within a
milestone, which I think is what you had in mind.

Arbitrary attributes are supported, so you could track point estimates that
way, but you're right, nothing like that is surfaced at the top level. Perhaps
we can think of a good way to surface things like this without reaching Jira-
custom-fields level of pain.

~~~
awaxman11
Thanks for the response! That's exactly what I had in mind re: ability to
order problems at a more granular level. Didn't realize that arbitrary
attributes are supported, that's great

------
foo123456
regarding the architecture: basically is (or is very much like) event
sourcing, right? I mean, kind of like an append-only log, that will grow
forever.

~~~
TheTon
(author here)

Yes, that's right, at least at the source of truth on the server. Clients
automatically rewrite or squash their local history a little bit prior to
pushing it to the server to minimize log length and to avoid showing
intermediate editing states that were never communicated to anyone else (just
like you might squash git commits), but every important state is preserved in
the log.

~~~
foo123456
ok tnx! as a dev myself, i'm still not convinced about this whole append-
only/time-machine approach (i'm talking more about event sourcing in general,
not your specific architecture). it smells too much architecture astronaut
(see
[http://www.joelonsoftware.com/articles/fog0000000018.html](http://www.joelonsoftware.com/articles/fog0000000018.html)
and
[http://www.joelonsoftware.com/items/2008/05/01.html](http://www.joelonsoftware.com/items/2008/05/01.html)).
it feels like this incredibly heavy monster system that _theoretically_ may
let you do anything, but in practice, at the end of the day, is not able to do
it because it is impractical to use. again, not necessarily yours.

~~~
mbrock
Git itself is exactly such an append-only system, and it's one of the most
reliable and useful tools ever. What's the problem?

------
coherentpony
It's strange to me that although distributed version control systems are very
popular, we all use centralised issue trackers for them.

~~~
kyberias
But it really isn't strange. Maybe because there is a lot of value in seeing a
real-time, shared, up-to-date view of the issues including status information.

------
randomor
Interesting angle approaching this problem, from a continuous log cacheable on
the client. Just downloaded and used demo briefly so take this for whatever
it's worth: \- What about a sidebar for the issue detail, instead of a
floating window? \- A send button when posting comment, not just CMD-S \- The
issues list could use some bigger font size and spacing

------
mLuby
Kudos for doing conflicts the right way!

------
lemming
I'd actually be interested in trying this, since I have a lot of issues and
I'm getting frustrated with Github issues. But I'd need my users to be able to
file and comment on issues online - it looks like this is not possible right
now. Is that planned?

~~~
kogir
Consensus seems to be that we need to build out the web client next.

We always planned to make a web version, but don't expect we'll be able to do
too much better than existing solutions.

~~~
lemming
Well, I think the "better than existing solutions" part is the offline client
- mostly I just need a web front end for users to get the issues into the
system. I'm happy for all the searching etc to be only in the desktop client.

------
chintanp
This looks awfully similar to a tool called as radar when I worked at a fruit
company in cupertino.

~~~
kogir
Honestly, it looks more like Mail.app. It really will if we offer a single
window mode.

My co-founder, James, most recently worked at Apple. Pretending he wasn't
influenced at all by (the good parts) of Radar would be disingenuous.

------
acgourley
What will the pricing be like?

------
quickpost
I like this. A lot. What's the pricing? SaaS vs one time fee?

------
tedmiston
Startups would love to use this if you building Jira compatibility.

------
Keats
You should mention in the article it's mac only

------
Laaw
What does 'native' mean in this context?

~~~
CodyReichert
In this context it means that the software was built specifically for Macs.
Ie, not a web/mobile app.

------
bifrost
Looks great!

------
pluma
s/native/OSX/

------
alienasa
Why OSX 10.10 or later?

~~~
kogir
We don't have older machines to test on, and we built it for ourselves first.

I use Windows, but a web client is probably next.

------
volaski
great domain! :)

~~~
TomorrowRich
my thoughts too

------
TomorrowRich
Why would you make it require Yosemite 10.10? This is absurd developer
laziness. Spend an hour making it compatible with OS versions from the last
couple of years.

There's no excuse for this.

~~~
PakG1
Out of curiosity, why wouldn't you upgrade? I know Yosemite had its issues,
but El Capitan seems better. I agree that having something available for
previous versions is probably a good thing. But just curious why you
specifically wouldn't upgrade.

------
TheJixers
We have built an alternative to Jira and we're always looking to improve our
product. Check out tool out - [https://jixee.me](https://jixee.me)

We're working with developers daily to make it a better experience.

