When it comes to technical sharing, I'm a big fan of figuring out first what can be gained and then figuring out a way of encouraging sharing in that direction. For me, at least, just lining up technical people in a common space and hoping sharing occurs has rarely yeilded value. But if I can get a few common causes going, then usually people will get a sense of each other and sharing will occur more naturally and organically at that point.
Particularly in software, here's some examples of focused knowledge exchange that yeilded good results:
External peer review - when the team is having design reviews, code reviews, or test reviews - invite 1 member of an external team. They probably have an out of the box idea or two based on their different perspective. They'll learn a little bit about the product, too, which is always helpful.
Lessons learned sharing - if a team does a lessons learned after a big release, invite some members of other teams. You can try to share notes and minutes after the fact, but the real discussion with all the agnst and excitement is really the value - so have other there for that.
Big success parties - even if it's just everyone grabbing a quick cup of coffee - invite all members of other teams as a courtesy.
The first two are tightly tied to a goal, and they usually have a fairly formal structure - that gives the foreign team members a structured way of knowing how to share and what's expected of them. For technical folks, that's usually really helpful, particularly when they don't share a common goal (their project).
The third is pretty fluffy and you'll probably only get the social folks to participate, but it can be a real morale boost - celebrating withing a team is one thing, but showing others that you had a big success motivating in a different way and it raised the morale of the company, because people find out that good stuff is happening in other places in the company - which is always a plus.
I am sometimes willing to try less pointed interaction - like technical presentations to the larger group - but I find that when such things aim to be generic enough to be widely useful, they can also be too fluffy to be interesting, unless you have a really good topic and a really good presenter. I don't count that as likely, as what makes a good presenter, vs. a good software developer are usually quite different things.
The bottom line to keep in mind is to have a certain sense of cost vs. value - when you drag EVERYONE into a meeting, it's a very expensive meeting (meeting time X number of paritcipants). If you instead seed the communication by selected (rotating) invitation to a meeting you'd have anyway - then you may get more bang for the buck - 1 or 2 cross team invitees may represent 70% of the knowledge of the whole team, giving you great value for a small amount of time given by just a few people. Once people realize that there are awesome smart people on other teams, they will tend to seek them out naturally.