
Show HN: Gitscout – A Beautiful GitHub Issues Experience for MacOS - jeremybenaim
https://gitscout.com/
======
brudgers
There's a little bit of marketing dissonance between the request that people
help build Gitscout by using Github and the absence of a Github repository for
Gitscout itself because the implication of using Github issues for bug reports
and feature requests is that the rest of the project is also accessible to
users.

I get that there's a business model behind the decision and that business
model is ok by me. Using Github for issues also seems like a reasonable
business decision. What is likely to create backlash is the _appearance_ that
Gitscout is trying to exploit the goodwill developers feel toward opensource
while keeping the code closed. There's no 'giving back' to go with the
'contributing'.

My advice is to demphasize that aspect of your marketing. It's a distraction
anyway because it's not a feature for users. Solicit feedback but not in a way
that might be interpreted as 'bait and switch'. The ill will it is likely to
generate will probably do more harm than good.

Good luck.

~~~
jeremybenaim
Hello brudgers. Thanks for pointing that out! I understand your point, but we
actually made sure to avoid any misunderstanding by asking to "share your
feedback on our Github" on a repository called "gitscout-feedback" with the
following description: "This repo is a place to report bugs, give feedback and
share ideas on how we can improve Gitscout" ️ That being said, if it's not
clear enough we'll definitely pay more attention on how to phrase our request
for feedback. Thanks!

~~~
brudgers
The emphasis that the link was a link to Github created an expectation. That
expectation was stronger because the project is about Github. The link and
it's presentation did not meet my expectations because they are contrary to
the values I associate with Github...e.g. open source.

For someone considering your project, the experience may be reading the title
and thinking "Github, that's good"; looking at the issues link and thinking
"Github, that's good"; and then following the link and thinking "WTF? where's
the code."

That's kind of my experience, except that I was not investigating tools, just
looking at your post. If I had been investigating tools, it would probably
have been enough to stop looking at yours even if I closed source tools were
acceptable. The reason is that there's a 'sense' that it is a violation of
trust.

Anyway, good luck again.

~~~
jeremybenaim
Ok I think I understand a bit more what you mean. Don't you think removing the
Github link in the header would make it less deceiptive? Thanks

~~~
brudgers
My advice is to avoid anything that might possibly create an expectation that
the project is open source. Pitching a closed source product to Github users
is probably tough enough without creating an excuse for people to have a
negative reaction.

Less deceptive isn't the best way to phrase it. Be upfront. Let people get to
'no' quickly if closed source rules the product out. That will let you
validate your business decision to make the product closed source. At some
point potential users will learn the product is closed source. Respect their
time, don't waste it.

In the end, your customers are going to be people who are ok with closed
source. An approximated sales pipeline:

1\. People who hear about your product are an approximation of prospects.

2\. Prospects who hear about your product and are ok with closed source are an
approximation of leads.

3\. Leads who are _shopping_ for a product like yours and are comfortable with
your price are an approximation of qualified leads.

4\. Your sales will only be to the approximation of qualified leads.

Effort spent on moving people with an aversion to closed source down the
pipeline is an inefficient use of resources if there actually is a market for
the product. It is inefficient because you have to sell your product _and_
convince the person they are wrong about closed source.

