I think it’s pretty important. It’s one thing to align with the open source ideal in general terms, and quite another to say how you’re going to do it and specifying which parts you won’t share. Mapbox’s strategy is to free the vast majority of of work, including algorithmic magic where ‘value’ is perceived, but to keep products and servers closed when they’re heavily specialized for our usage or would enable competitors. So the focus is on open sourcing modules. Modules are the liquid assets of open source - easy for one group or another to adopt and swap in, and of real use across industries.
There are other models that are well-documented. MySQL does dual-licensing, which is Steve Coast’s bet. Boundless Geo (previously OpenGeo) does services, support, certifications. This strategy works for installable software in an high-end enterprise setting where you have a large staff that’s customer-facing - handling support is a full time job.
Major companies have released big contributions to the ‘open source community’ - like Facebook’s React, Google’s Angular, and Microsoft TypeScript. But these aren’t their products: the code for Facebook.com, Google Search, and Windows isn’t open. Given the advent of ‘cloud’ applications, there’s much less of expectation that products & servers are released, and the industry-wide movement from GPL-style licenses to BSD-style licenses makes it simple and legal.
There are other paths. TileMill was supported by a Knight Foundation grant. There are other organizations, like Mozilla and Open Whisper Systems that are funded by continuing donations and odd business deals. 18f is funded by taxes.
At Mapbox, the stuff we open source is all of the parts of our core product, except, sometimes, the product itself. I think this lines up with Mikeal’s theory on how open source should be done. It separates things that require customer support and servers and that are aimed squarely at a single usecase and environment from those that are generally usable. For our open source projects, it makes the relationship straightforward: we build parts to build the product, we invest time in community-things like documentation and packaging, and we can be straightforward about the problems they’re solving and whether contributions will be accepted.