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.
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.
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.
Yeah, Red Hat is really bleeding money from the all the lost sales caused by CentOS. I can't believe they only made a puny 1.53 billion dollar in revenue last year..
</sarcasm>
Red Hat has never made money because of its GPL software. People want to buy their support and consulting services, which Red Hat incidentally only offers for RHEL, necessitating users buy a license if they are to get the product they actually want. People who try to sell GPL software as a standalone product do not fare well.
Please note that the HN community takes a rather strict approach when moderating comments that contribute noise to the conversation. "Nice article!" comments are routinely downvoted. As is sarcasm, witticisms, memes, references and other styles of comments that occur frequently but do not contribute to the discussion. It's a knowingly doomed attempt to hold back the flood of noise that covers Reddit.
The parent comment, however, was actually relevant to the point being discussed (whether or not the ability to fork a free-as-in-speech but not free-as-in-beer program is a significant risk to one's business model). Sarcasm or no, it's a valid point, and thus I feel trying to spout off admonitions in the name of the "HN community" is inappropriate in this context.
Yeah, this was iffy. I totally agree with the comment. But, when it comes to maintaining a community, it doesn't matter if you are right if you are a jerk about it.
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.
VA Linux Systems set a record for largest IPO and then tanked. The vast majority of Free-software based businesses have tanked too. RedHat is really the exception.
VA Linux Systems was a Hardware Company so your comparison fails in terms of speaking about Free Software Success Stories. Red Hat is far from being an exception. Actually old school closed source software companies are more difficult to start up today in my opinion.
Financial Success Stories abound all around. MySQL, WordPress, Drupal, Mozilla (FireFox), Android, etc.
None of those make money selling GPL software. The GPL software undergirds the product they sell, but it is not the product itself.
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).
Yes. Does that change something? Red Hat finally acquiesced after 10 years. They started out threatening CentOS with a lawsuit, leading to the infamous "prominent North American enterprise Linux vendor" language that plagued CentOS's site until this deal was announced last year. If anything it's only further evidence for my argument.
GPL Encourages it doesn't discourage the charging of software. Please give me one source where they discourage charging fees for software. In regard to copyright you are 100% correct, but the GPL is copyleft not copyright. You can't blend in copyright and Open Source those are two different things unless the latest Google vs Oracle API fiasco follows through.
My favorite IDE RStudio is AGPL which offers a Open Source license that also allows them to charge for added features.
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]
You can always dual license, and sell the second, commercial-friendly license for a price. You need to be careful that you're the sole copyright holder though, so you need a strong contributor agreement.
Sure, but this is not selling GPL software. This is giving GPL software out for free, and selling proprietary software.
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.
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.
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).
While the source is free you can bump into trademark issues (I don't know if it's specifically true for MobaXterm though). You can go the CentOS or Iceweasel way, download the source, replace trademarked stuff and distribute the compiled binaries.
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.
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.
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.)
> 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.
The difference between #4 and #5 has to do with expectations.
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.
>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.
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.