Why do I need a GitUp account to enable rewriting commits?
Furthermore it looks like these prerelease builds expire. I'm guessing the released software will be neither free nor open source.
Why do I need a GitUp account to enable rewriting commits?
Furthermore it looks like these prerelease builds expire. I'm guessing the released software will be neither free nor open source.
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.
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.
Look at mobaxterm [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]
This is also the reason why I don't like the term Free Software since people usually think it is speaking about the cost.
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
For the discussion: I recently paid for the Synergy software KVM even though it is GPL. Synergy's purchase process is very smooth. Paying $10 for the installers was much easier than compiling it myself. And, I was already had confidence that Synergy was useful, good quality, well-maintained software. So, I was happy to support it as long as doing so was convenient.
Financial Success Stories abound all around. MySQL, WordPress, Drupal, Mozilla (FireFox), Android, etc.
MySQL: Fancy proprietary version with non-GPL features makes money, GPL version sits there doing nothing. Used to make money from a traditionalist dual-license model before Oracle took over, now they just neglect the GPL version.
WordPress: Makes money from hosting and consulting, not from its software.
Drupal: ibid.
Firefox: makes money from search affiliate deals and charitable donations. This is closer because they make money by getting brands in front of Firefox's installed base, which is sort of close to making money from software, but still indirect.
Android: Google does not make money from Android directly except insofar as they negotiate licensing deals with phone providers for their closed-source "Google Apps" suite and/or for "Google Play Edition" or other official branding on a phone. In these cases, they are selling a collection of Android apps and/or Google branding, not the GPL software that runs on the phone.
I don't know of any case where a company sustained itself on the sales of actual GPL software. Every open-source company lives off ancillary services or licensing deals (dual-licensing like MySQL or branding deals like Google).
http://www.redhat.com/en/about/press-releases/red-hat-and-ce...
My favorite IDE RStudio is AGPL which offers a Open Source license that also allows them to charge for added features.
http://www.rstudio.com/pricing/
AGPL - The GNU Affero General Public License is a free, copyleft license for software and other kinds of works, specifically designed to ensure cooperation with the community in the case of network server software. [http://opensource.org/licenses/AGPL-3.0]
I'd be interested in cases where people have made substantial money selling GPL software as if it were proprietary software; that is, where they are able to get the consumer to pay for the software after a short trial, in order to retain the privilege of using the software long-term. The GPL grants this privilege anyway, which is the problem. The consumer doesn't gain any value by exchanging their valuable money for something they already have (the right to use your software), so they don't do it.
I don't want to do that, cause I'd prefer they get more money, but it's neat to know. (I'll double check the license of course.)
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.
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.)
> 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? :)
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.
When you download a free app, and then you discover that you need to pay for some features: That's a slap in the face.
When you download a trial of a paid app, and then you discover that you can get pretty far with the features of the free trial: That's a pleasant surprise.