Qt / Nokia ramping up open source involvement
May 28th, 2009Business, Development, Open Source 17 Comments
I reported a few months ago on how pleased I was that Qt was changing license to the LGPL, something I saw as a watershed for Qt adoption. I already had an awful lot of respect for Qt, but the previous GPL/commercial license did mean that adoption was in two quite widely separated camps – those who were already making GPL software, and those that could afford to license it for other cases. Great though Qt is, the price of the commercial license is really quite steep ($3,695 per-developer, per-platform), and that was hard to justify for a small developer.
So, the LGPL move is a big change and opens up a huge opportunity for Qt to be adopted in the ‘middle ground’. But beyond just adoption, Qt are clearly pushing for much higher levels of community participation going forward. A couple of weeks ago I got a call from someone in their strategy group, who is looking to reach out and build relationships with other open source groups & companies in related fields, to see how we might help each other in the future, and that sounded really promising. Today I received an email from the Qt mailing list outlining how they’re structuring their new public code repositories, and how they’ll be accepting external contributions. It all looks well thought out – they’re using Git to make patch submission easier on a large scale for example (something I’ve considered in the past, it’s only unfamiliarity and the lack of good Git UIs that puts me off doing it).
It’s great to see big companies making such solid moves into true open source participation like this, as opposed to some other companies which use open source licenses, but still operate a 100% ‘push’ model of development. Ultimately I’m sure it will pay huge dividends both for them and for the Qt user community. Obviously before the Nokia aquisition, Qt had to generate all its revenue from licensing so it had less scope or impetus to explore openness like this, but still I think there’s scope for many organisations to explore this approach with some aspects of their software products; specifically those parts that underpin the ‘premium’ side of its business or provide other infrastructural elements on which it builds its higher-margin offerings. As more companies explore these kinds of opportunities to blend open source and commerce, both as providers and consumers (and open source offers benefits on both ends of the relationship), I think we’ll see an acceleration of iterative innovation in the industry.
May 28th, 2009 at 6:38 pm
Try Git-Cola, it’s nice.
It’s based on QTPython, and feels better than the standard git gui.
May 28th, 2009 at 8:37 pm
@jacmoe: thanks, congrats on tying together 2 of the subjects of the post in one swoop (Qt/Git)
Git-Cola still looks confusing to me, but then I don’t really understand Git properly yet. I need to play with it somewhere I think.
May 29th, 2009 at 3:06 am
I love how stupidly simple TortoiseSVN is, so until there’s a git equivalent, I’ll be sticking with that.
Git’s general way of doing things does make a lot of sense to me, but while I enjoy a good romp in my Linux box’s PuTTY session as much as anyone, the less distractions I have while I focus on the task at hand, the better.
May 29th, 2009 at 10:56 am
@Frenetic: I *have* TortoiseGit installed (Google.code), and it has come a long way. It works for most things. Didn’t mention it because it’s Windows only. Prefer Cola because it fits the Git workflow better, IMO.
@Steve: Thanks. Couldn’t resist.
May 29th, 2009 at 2:57 pm
TortoiseGit is very buggy, and it works like SVN, not Git, which is a different workflow.
Anothers gui are: Gitk(integrated in git), Qgit, and if u use Macosx there’s a good one that i forgot about its name.
Steve, first read some minibooks about Git, like: Git internals, Git from bottom to up(very good one) or Git Magic. After reading those u will get a simple conlusion: SVN is useless, VCS is stupid, and Git rules them all.
Hope to help u.
May 29th, 2009 at 3:44 pm
See, I’ve read ‘Git from bottom up’ and it had the opposite effect to probably what you intended – all it did for me is confirm that Git is *way* more complicated than I need. It’s very clever, and I like many of the core concepts, but the sheer number of commands and gnarly things you can do just seem to invite the uninitiated to tie themselves in knots. The advantage of SVN is that pretty much everyone can get started with it very easily and know exactly what they’re doing. I’m concerned that using Git would just confuse the hell out of a lot of people and put them off using the repository version.
That’s partly why I’m waiting for a Git UI that actually makes this simpler, hides all the clever stuff that most people don’t give a damn about 95% of the time, and doesn’t require every user to wade through something like ‘Git from bottom up’ before knowing what they’re doing. Or, maybe Git is just way overkill for what I want to do, and I’ll just leave it to the ‘real’ coders
May 29th, 2009 at 5:01 pm
I see your point of view and partially i agree. SVN is very simple, i recomended and i’m using it at work(well, i use git-svn to work with our own repos). I choose SVN vs another VCS, because:
-It’s easy to use (with tortoise)
-Some third parties think that its the natural evolution to CVS, so they have no problem adopting it
-It had so much hype when it was released
But… Git gives me so much control. And Yes. I use Gitk, tortoiseGit(for some things) and MsysGit console to do all my workflow. It’s overkill, overcomplicated…But after repeating commands, using Rebase, CheryPick and having my own local branches not visible with anyone. I think that i have more to win and very little to lose.
I’m very interested in how do you do your workflow with svn, a centralized VCS. If you need to test a new private feature, how do you do it? You copy your trunk dir and start coding…, How do you avoid merge hells…
May 29th, 2009 at 5:13 pm
SVN is definitely not simple when it comes to branching and merging! That’s where I stood off.
For a good guide to Git, I recommend Git Magic:
http://socghop.appspot.com/org/home/google/gsoc2009/wx
The quick start at GitHub is not bad either:
http://github.com/guides/git-cheat-sheet
Anyway, to get back to the topic:
I am really excited about QT Creator!
If it’s only half as good as it looks on that intro video … Gotta check it out.
May 29th, 2009 at 5:21 pm
@ASpanishGuy: Since I ‘own’ the repository, I’ve never had a need for a ‘private’ feature
When I do need a ‘WIP’ mod which isn’t ready for prime time, it either exists as a patch, or as an ‘unstable’ branch if it’s long-running (e.g. major, multi-stage breaking changes, Summer of Code etc). These things are fairly rare and so far the patch/branch workflow works perfectly well. The place Git might help is for the wider community exchanging their own experimental modifications between themselves, but honestly it’s not *that* difficult to do it via patch files anyway. So I can see how Git might help, but on balance I don’t think the complexity is really justified for the small number of cases (for us) where it would make a perceivable difference.
Merge hell? Very occasionally it can be tricky with large patches, but really not very often. I think a bigger project with more heavier external branching might have this problem, but we rarely have. And it seems to me that Git doesn’t (can’t?) entirely solve these problems anyway, it just helps you with them, but only provided you understand its labyrinthian mechanisms.
@jacmoe: I find SVN branching easy, but that’s because it uses the same approach every other centralised source control system has used in the last 20 years, so I’m very used to it.
May 29th, 2009 at 6:22 pm
I’m not talking about integrating patches in your main trunk, i’m talking about this Use case when i work with SVN:
-Thunk is at Revision 1000 and i want to test a new Experimental Renderer in Ogre, so i checkout thunk, copy it to a new dir (named exp_render). This new render will take a month, so each progress i do i want to commit. But i can’t. My “local” branch(just a mere copy of thunk), as it’s not a real SVN branch(because i don’t want it to be vesisble to others), can’t be commited. Any attempt to do it will commit to trunk.
So my question is, who do you resolve this? Posible solutions(i did them before)
-Each time that u want a commit, u do a zip of that dir, so you some sort of snapshots, but Diff, search in previous commits is lost
-You create a local SVN repo, copy all your trunk files to it, and you get a “local” copy, but u lose the “update” sync to master(original) repo. So when u need to apply your patch after a month, the trunk is at revision 1500, and u get a lot of merge conflicts…
That use case shows the advantage of DVCS, and git, mercural, bazaar shine here.
May 29th, 2009 at 6:24 pm
I was using Git as our in-house source control until we just finished the migration to TFS today
My company is part of the Microsoft BizSpark program so we get full MSDN free for three years which is really nice. I was extremely happy with Git but I loved the integration of everything in TFS.
Regarding Nokia/Qt I am really glad to see them moving with the open source community. I was torn between Qt and Wx (I much prefer Qt as usually it is much cleaner code, but the license was fairly restrictive) until the announcement, and at that point the decision was made to use Qt.
May 29th, 2009 at 6:27 pm
Git was at the top of my list when I was tasked with evaluating distributed version control systems at work. Like you, I was put off by its steep learning curve, so I moved on to Mercurial and Bazaar. Bazaar offered us what seemed at the time to be just the right balance of flexibility and familiarity. (We were Subversion users at the time.)
We’ve never looked back. Before, we were always hesitant to branch because of the overhead incurred from the merging process. Now we are branching fools. We branch for new features, large overhauls, and minor, isolated changes alike. Our trunk stays stable and we approach sweeping changes to the code-base with a marked increase in confidence.
But you sound like you are considering DVCS primarily with an eye toward user-contributed branches, so I’m not sure how relevant our closed-source experience is. Nevertheless I encourage you to check our Mercurial or Bazaar the next time you are in a DVCS frame of mind.
May 29th, 2009 at 7:09 pm
@ASpanishGuy: I just don’t have this problem, at all. Like I say, I have commit access so I will usually commit WIP to the main repos anyway. If there’s a reason I can’t, because the changes are breaking, I’ll commit them to a separate branch and merge them in when it’s all done. Or, if it’s short-term, I’ll keep patch files as backup or to share with others.
Your example of merge conflicts is highly exaggerated. We use multiple branches all the time (stable, development, Summer of Code etc) and merge conflicts are generally minor and easily resolved. I honestly think that people overplay this issue when talking about Git et al – or maybe they just have vastly more complex projects than I have with way more overlapping and conflicting changes. Generally, they rarely happen in Ogre, and in most other projects I’ve contributed to over the last 15 years. Funnily enough, people managed before Git
I like the distributed features of Git et al for sure, I just question how many projects really have the kinds of merge problems that are typically rolled out as justification for the increased complexity. Even large projects I’ve been involved in with lots of developers / commits have ended up with most of those commits scattered around the repository, with very few conflicting overlaps in practice. That’s not to say they’re not useful, but on balance is using Git easier / more productive than SVN? I’m yet to be convinced. YMMV though. A really friendly Git UI or some other DVCS which includes these features but manages to hide the complexity in most everyday use might help to convert me. Something that makes rare edge cases easier, but everyday use harder (or just more complex) is not a sale for me. I want both!
May 29th, 2009 at 7:12 pm
For things like that: just do multiple checkouts?
I am experimenting with using SVN and Git together: Just checkout from SVN, and do a git init on it. (Not git-svn, it has some issues).
That way I can have it both ways: SVN for remote and Git for local.
May 29th, 2009 at 7:23 pm
@goomf: thanks – now I have to find time to try out 3 new systems!
I tend to think of Git because it’s the fashionable one but admittedly that doesn’t mean it’s the best option.
May 29th, 2009 at 8:03 pm
@jacmoe: At begining i was doing that, but git-svn is much better (i’m using msysgit 1.6.3 with a 1.4 svn repo, msysgit guys said that svn is not supported or broken, but i have it working with some minor problemseasily fixable).
@Steve: Git has poor gui tools and the learning curve is quite high. So if you are good with SVN, and you have no problems, there’s no problem on continue using SVN. Dont waste your time learning a new tool if you are happy with the old one and have no time. Be pragmatic
@jacmoe:i just installer git cola, and i like it. Still i’m missing custom commands that git gui supports, but it’s a nice frontend.
May 29th, 2009 at 8:18 pm
I may be happy with SVN, but I still like some of the ideas in a DVCS, so I’m not ruling out using one in the future. Everything changes given time!