6 ms·

Anything can happen (I have a number of projects that are open-source, some other close-source), but the idea so far is to have a free app with an in-app purcha

Anything can happen (I have a number of projects that are open-source, some other close-source), but the idea so far is to have a free app with an in-app purchase to unlock the advanced/pro feature. I might make open-source some of the "Git toolkit" I built for this app, but it's too early to say. The reason for expiring builds is that 1) it's pre-release, 2) it's a software intended for professional engineers and 3) the app is rapidly evolving, so I don't want to have people using old versions which may have bugs fixed since then: http://forums.gitup.co/t/gitup-release-notes/16 http://forums.gitup.co/t/gitup-release-notes/16.

oldmanjay 11y ago
What made you decide where the line is for "advanced" features? It seems like doing any sort of actual work is considered advanced. There isn't a feature I can think of that would make me consider paying for development tools, so I'll never be buying your software, so feel free to tailor your response (if any) with that in mind.
- swisspol 11y ago
  Fair question. It's not decided yet. The easiest code-wise was to put the Map editing features in that bucket, so that's what I did for now. Everything else (browsing, committing, stashes, repo config, undo / redo, cloning...) is free and no registration needed.
baldfat 11y ago
You don't need to make an application closed source to have in app purchases. Look at mobaxterm [http://mobaxterm.mobatek.net/license.html http://mobaxterm.mobatek.net/license.html] It is licensed under GPL version 3. It has a free version and a professional version which cost $69 per user. This does not break the GPL. You may already know this but it seems like a lot of developers think open source mean Free as in cost. [http://www.gnu.org/philosophy/selling.en.html http://www.gnu.org/philosophy/selling.en.html] This is also the reason why I don't like the term Free Software since people usually think it is speaking about the cost.
- swisspol 11y ago
  Yep, aware of it, I happen to have 3 apps on Mac / iOS App Stores already using this model :) - https://github.com/swisspol/ComicFlow https://github.com/swisspol/ComicFlow (quite popular) - https://github.com/swisspol/MP3CDMaker https://github.com/swisspol/MP3CDMaker - https://github.com/swisspol/CompareFolders https://github.com/swisspol/CompareFolders
- cookiecaper 11y ago
  Although the GPL allows authors to charge for software, it disposes of all legal copyright protections that make such charges practical. Charging for GPL software doesn't mean anyone will pay you, it just means that everyone will get the free builds from someone else, which is even less desirable than releasing free builds since you lose control of distribution. Look at Red Hat and CentOS for case in point.
  - dec0dedab0de 11y ago
    umm.. Red Hat seems to be doing ok.
    - lmz 11y ago
      Red Hat does OK because they can sell support for an OS to enterprises. Selling support for a Git GUI to individual developers (even end user apps in general) is a bit harder.
      - baldfat 11y ago
        Please look at mobaxterm's model for an example. GPL licence [http://mobaxterm.mobatek.net/download.html http://mobaxterm.mobatek.net/download.html]
        lmz 11y ago
        They provide integration of open components (which is good). Looking at their sources directory there does not seem to be an available build script to e.g. build a comparable installer (but that's legal). For a single app: take a look at what happened when XChat tried to sell their Windows binaries as shareware: http://en.wikipedia.org/wiki/XChat#Licensing http://en.wikipedia.org/wiki/XChat#Licensing
riscy 11y ago
>in-app purchase to unlock the advanced/pro feature Preying on new git users when they need to do something "advanced" with their repository is pretty low. >The reason for expiring builds is that [...] 3) the app is rapidly evolving, so I don't want to have people using old versions which may have bugs fixed since then Controlling whether I can use the software just because it's an old build? You've gotta be kidding me. No thanks.
menssen 11y ago
Just a thought: I sort of agree with the fact that "pay to use git in a more advanced way" is a bit of a slap in the face to new users. For me, what I absolutely love about this is the quick view of changes in a commit. My usual workflow for this is 1. git log --oneline --graph 2. Copy commit hash to clipboard 3. git show <paste commit hash> or worse 3. git difftool <paste hash>^ <paste hash again> which is clunky as hell, and made worse that difftool operates on a single file at a time. GitUp is the first application that I don't hate using that solves this problem. So my suggestion is: remove ALL the modification features from the free version, release it as a separate app called "GitUp Viewer" or something, and then sell the version that is actually a git client. (Now it just sounds like I'm trying to avoid paying you for your work, but anyway.)
- swisspol 11y ago
  Thanks for the kind feedback! > So my suggestion is: remove ALL the modification features from the free version, release it as a separate app called "GitUp Viewer" or something, and then sell the version that is actually a git client. Hmmm... but wouldn't that be exactly the same problem of "slapping users in the face", except now with 2 apps? There aren't that many options to distribute desktop software: 1) freeware 2) free to use but ads or equivalent 3) paid upfront 4) paid with trial 5) paid with in-app purchase for some features 6) a free basic app and a pro app #1 and #2 are not an option here and #6 is too much overhead and complicates the user proposition. I don't see how #3 is not worse than #4 and #5. Not an option either anyway: I truly think people should be able to try before they buy for such a product. #5 is all the trend on mobile and has been demonstrated to work (I've also done that on a couple desktop software and it seems OK). IMO it's the best of both worlds if done right: you get a free useful product as-is, but pay to get even more value of it. If you think #5 is a "slap in the face of new users", wouldn't #4 also be that? :)
  - menssen 11y ago
    Here's a specific scenario: I work at an organization with a lot of developers who first learned to use git through SourceTree. As far as they are concerned, "what SourceTree can do" is the entirety of how git works. While this is probably not great overall, I do think it is the experience of a lot of newer git users or people who aren't used to a CLI. I also work at an organization where it is difficult (mostly just annoying I guess) to get software purchased. What I am afraid of is a bunch of people learning to use git through GitUp, and when I ask them to rebase something, they say "I can't because I don't have the pro version." Or even worse, some organization saying "we won't buy this for our developers because the free version does everything we think they need to do." IMO, responsibly managing a git repository requires using a wide variety of the tools that git provides. Creating a situation which artificially categorizes those features into "essential" and "advanced" is bad for people learning git, because they probably should be learning those advanced things sooner rather than later. I guess my vote would be (4) paid with trial, falling back to "view mode only" at end of trial.

oldmanjay 11y ago

What made you decide where the line is for "advanced" features? It seems like doing any sort of actual work is considered advanced. There isn't a feature I can think of that would make me consider paying for development tools, so I'll never be buying your software, so feel free to tailor your response (if any) with that in mind.

swisspol 11y ago
Fair question. It's not decided yet. The easiest code-wise was to put the Map editing features in that bucket, so that's what I did for now. Everything else (browsing, committing, stashes, repo config, undo / redo, cloning...) is free and no registration needed.

baldfat 11y ago

You don't need to make an application closed source to have in app purchases. Look at mobaxterm [http://mobaxterm.mobatek.net/license.html http://mobaxterm.mobatek.net/license.html] It is licensed under GPL version 3. It has a free version and a professional version which cost $69 per user. This does not break the GPL. You may already know this but it seems like a lot of developers think open source mean Free as in cost. [http://www.gnu.org/philosophy/selling.en.html http://www.gnu.org/philosophy/selling.en.html] This is also the reason why I don't like the term Free Software since people usually think it is speaking about the cost.

swisspol 11y ago
Yep, aware of it, I happen to have 3 apps on Mac / iOS App Stores already using this model :) - https://github.com/swisspol/ComicFlow https://github.com/swisspol/ComicFlow (quite popular) - https://github.com/swisspol/MP3CDMaker https://github.com/swisspol/MP3CDMaker - https://github.com/swisspol/CompareFolders https://github.com/swisspol/CompareFolders
cookiecaper 11y ago
Although the GPL allows authors to charge for software, it disposes of all legal copyright protections that make such charges practical. Charging for GPL software doesn't mean anyone will pay you, it just means that everyone will get the free builds from someone else, which is even less desirable than releasing free builds since you lose control of distribution. Look at Red Hat and CentOS for case in point.
- dec0dedab0de 11y ago
  umm.. Red Hat seems to be doing ok.
  - lmz 11y ago
    Red Hat does OK because they can sell support for an OS to enterprises. Selling support for a Git GUI to individual developers (even end user apps in general) is a bit harder.
    - baldfat 11y ago
      Please look at mobaxterm's model for an example. GPL licence [http://mobaxterm.mobatek.net/download.html http://mobaxterm.mobatek.net/download.html]
      - lmz 11y ago
        They provide integration of open components (which is good). Looking at their sources directory there does not seem to be an available build script to e.g. build a comparable installer (but that's legal). For a single app: take a look at what happened when XChat tried to sell their Windows binaries as shareware: http://en.wikipedia.org/wiki/XChat#Licensing http://en.wikipedia.org/wiki/XChat#Licensing

riscy 11y ago

>in-app purchase to unlock the advanced/pro feature Preying on new git users when they need to do something "advanced" with their repository is pretty low. >The reason for expiring builds is that [...] 3) the app is rapidly evolving, so I don't want to have people using old versions which may have bugs fixed since then Controlling whether I can use the software just because it's an old build? You've gotta be kidding me. No thanks.

menssen 11y ago

Just a thought: I sort of agree with the fact that "pay to use git in a more advanced way" is a bit of a slap in the face to new users. For me, what I absolutely love about this is the quick view of changes in a commit. My usual workflow for this is 1. git log --oneline --graph 2. Copy commit hash to clipboard 3. git show <paste commit hash> or worse 3. git difftool <paste hash>^ <paste hash again> which is clunky as hell, and made worse that difftool operates on a single file at a time. GitUp is the first application that I don't hate using that solves this problem. So my suggestion is: remove ALL the modification features from the free version, release it as a separate app called "GitUp Viewer" or something, and then sell the version that is actually a git client. (Now it just sounds like I'm trying to avoid paying you for your work, but anyway.)

swisspol 11y ago
Thanks for the kind feedback! > So my suggestion is: remove ALL the modification features from the free version, release it as a separate app called "GitUp Viewer" or something, and then sell the version that is actually a git client. Hmmm... but wouldn't that be exactly the same problem of "slapping users in the face", except now with 2 apps? There aren't that many options to distribute desktop software: 1) freeware 2) free to use but ads or equivalent 3) paid upfront 4) paid with trial 5) paid with in-app purchase for some features 6) a free basic app and a pro app #1 and #2 are not an option here and #6 is too much overhead and complicates the user proposition. I don't see how #3 is not worse than #4 and #5. Not an option either anyway: I truly think people should be able to try before they buy for such a product. #5 is all the trend on mobile and has been demonstrated to work (I've also done that on a couple desktop software and it seems OK). IMO it's the best of both worlds if done right: you get a free useful product as-is, but pay to get even more value of it. If you think #5 is a "slap in the face of new users", wouldn't #4 also be that? :)
- menssen 11y ago
  Here's a specific scenario: I work at an organization with a lot of developers who first learned to use git through SourceTree. As far as they are concerned, "what SourceTree can do" is the entirety of how git works. While this is probably not great overall, I do think it is the experience of a lot of newer git users or people who aren't used to a CLI. I also work at an organization where it is difficult (mostly just annoying I guess) to get software purchased. What I am afraid of is a bunch of people learning to use git through GitUp, and when I ask them to rebase something, they say "I can't because I don't have the pro version." Or even worse, some organization saying "we won't buy this for our developers because the free version does everything we think they need to do." IMO, responsibly managing a git repository requires using a wide variety of the tools that git provides. Creating a situation which artificially categorizes those features into "essential" and "advanced" is bad for people learning git, because they probably should be learning those advanced things sooner rather than later. I guess my vote would be (4) paid with trial, falling back to "view mode only" at end of trial.