No, I mean something else. Do they license network code for the client from Valve? Or it's free? If they license it and Valve goes bust as a company (not Steam as a service downtime). Would they be able to still redistribute the code with the game or not? If not, they'll have to rewrite that code.

You can say that, but you can't guarantee that. Companies come and go. That's why having a core dependency on a proprietary middleware can be risky if it's hard to replace. A classic lock-in issue. Sometimes there is little choice and such trade-off needs to be made, but not in this case. There are tons of network libraries out there, no point to use any Steam for that. Avoiding the distributor lock-in is IMHO a very important factor for any developer.

If Valve goes bust or otherwise shuts down Steam, the Steamworks-bound netcode will not work as the back-end network is no longer running. The code will have to be rewritten regardless of whether or not it is free. While Steamworks has no monetary cost associated with it (as far as I know from the information I have seen), there is most certainly some sort of license associated with it though I'm quite sure it does not limit mere distribution (the libraries are rather useless without Steam anyway).

Haven't developed using SteamWorks, so can't really say. What I recall though is that SteamWorks is free.
As for the code part, it is quite possible that it connects to a server (public API), then it has a "Send net packet to player" and "receive net packet from player". What the packet contains is game based, how the packet is transmitted is Steam based. If steam upgrades its net code, existing games do benefit without any code changes. Add to it a "Select random player with equivalent skill" algorithm that is steam based, and game code is only "Quick Match".

As I said before though, all the above is speculation. And I would like to know what network libraries are there to provide matchmaking (not "Connect to xxx", but find random player functionality).

There are tons of network libraries out there, yeah, so you'd say writing a proper netcode should not be an issue anymore. That's not the case however - even Minecraft, which relies on multiplayer, has been a pain to get running properly amongst me and my two friends. That's just 3 people, and we have spent several hours that we could have been playing a game getting the bloody thing running properly - 2 of us network engineers. Fat chance of your average user getting it working at all under the circumstances. The next day it didn't work yet again, so we just said screw it and went to play Left 4 Dead 2, which worked flawlessly on the first attempt. And it's not just Minecraft - some games work reasonably well, but many more just ... Don't. We don't have particulary good connections, but that doesn't change the fact that games with Steamworks have always worked for us, on the first attempt, absolutely without any issues. Now can you see why would devs opt to use the damn thing? If an average user can't get MP working in your MP orientated game properly, he'll just stop playing and is much less likely to buy anything by your company ever again.

And all of that is just the net code - to get all the functionality I have mentioned, you have to use a lot of libraries and other 3rd party dependencies, which brings me to my next point:
That you're independent when using an open source dependency is a fairly common misconception. It seems that way, sure, but just as Valve can shut off Steam, so can any Open Source project die off at any point in time. When that happens, you have 2 options - either you dig into the code of the dependency, understand it, and provide your own tweaks and support. Now if you had time and money to do that, you'd just write your own resources in the first place, so you end up at the same spot - support has been dropped, with updates to OS compatibiliti will be broken sooner or later, so you either take out the functionality or write your own code. Same as with Steam.

I'm going to finish this post off with a situation that I have actually been in - the company I work for had two options: Either spend a fairly crazy amount of money on a third-party dependency, or write everything by ourselves. The company has opted for the former. Why you ask? Well, because our development time was suddenly cut in third. About two months instead of six, we have secured customers we wouldn't have otherwise, and in the long run, we have saved a lot of money.

Developing network games is not a piece of cake. No one said that it's trivial. If people can't handle writing professional code for it, let them stick to single player. It's not a good excuse to use Steam-locked libraries. If Steam is so willing to benefit the developers, let them release their libraries without dependency on their backend. If they don't want, they can get lost. At least that's how I'd be thinking from the project perspective Libraries can be commercial - that's not the worst case. But being tied to one distributor or backend service? No thanks.

Why? If you can't handle writing proper netcode and want to make an MP game, why would you limit yourself if the tools are freely available? It makes no sense, worst thing that can happen is that the game will eventually become unplayable - which it will anyway as there's a very high probability of people quite simply not playing your game anymore a couple of years down the line.

Now, I can see why would you, personally, not use such a service, and that's perfectly fine. There are devs who opt not to use it - if it's an MP title, I personally am less likely to get it due to my bad experience, but other people will like the independence of Steam. But throwing around bold statements such as 'If people can't handle writing professional code for it, let them stick to single player. It's not a good excuse to use Steam-locked libraries', 'it's lame to use such thing as a dependency' etc. just make you sound a tad ignorant. I guess 'At least that's how I'd be thinking from the project perspective' is the biggest issue here - from what I gather, you're not actually thinking from the project perspective. If you were, I'm fairly sure you'd see realities of development a tad differently.

Tying their users to Steam is bad. That was my point. Like the developers quoted above saying 98% of their games use Steam. If that's because of inability to write good network code, it's not a good excuse from my perspective. Sure they can do whatever they want. But if the end result is "Steam only", I'm not interested and don't consider such result professional. And I'm actually thinking from the project perspective. Hard dependency on Steam is not something I'd recommend to any serious project.

Why should they avoid it if a majority of their paying customers use Steam? I understand what you are trying to say but not everyone believes in same ideals as you and follows them. Fenixp has a point. If developers don't have a problem with Steam and are tempted to provide multiplayer in their game, it can save them work and help them to make more money.

My problem with that is their requirement "use Steam or don't get our game". It's not professional. Sure they cane save resources on that potentially. But when too many corners are cut, the product can't be considered having an adequate quality from user's perspective and from perspective of developer peers. Steam only product caused by requiring Steam network code is unprofessional from both perspectives.

Define what a 'serious project' is. Shogun: Total War is not a serious project? Dishonored is not a serious project? In gaming industry, AAA titles define what a 'serious project' means. Well it doesn't really mean anything, it's really a term you have just made up - but you get my point. As far as quality assurance goes, you don't get better than AAA projects. And QA is the only measurable way in which you can call a project 'serious'.

You are also avoiding a lot of points I have made, so I'm going to sum them up again a little bit:

- Let alone inability, writing and testing a net code takes away from development time of other aspects of the game. Now even with the Steam API, you have to write it anyway, obviously - but a lot of headaches associated with it are not on your shoulders anymore. What if a developer decides to forbid a part of his potential user-base to make a better game? And do keep in mind that coding all the stuff yourself, regardless of your ability, directly takes away time from the development of your game. Basically, coding it yourself means you're going to make much more compromises in the game itself, effectively creating a smaller / less tested / worse product. How do you suggest developers get around this issue? It's a bit of a rhetorical question really, they can't.

- What about all the other aspects that Steamworks provide and you have ignored? You keep talking netcode, but for some games, modding can be just as important. Or other things, like business model - free2play titles are going to have a much easier time using Steamworks. Patching, community features... Do you propose developers make all of that themselves? Do you realize how much development time would all of this take up?

- What about the issue of relying on on-line communities for support? You see, if you take your product on Steam and write up an agreement with them, Steam guarantees you that as long as it exists, you will get support and they won't do anything to just flatout break your game - because when they do, they're in a world of trouble. You have a guarantee that the API you are using will be up to date and functional and you are genuinely backed by a very powerful company. The first thing that most open-source project give you is 'We don't guarantee that our software will work with yours in any way, shape or form' - and that's just not enough.

Now you would actually be in a much stronger position if Steam was Windows-only, but it's not. You get a multi-platform API for all your needs. As I said, it would be amazing if such an open-source API existed - but it just doesn't. Developers can either opt for giving a lot less development time to their game or to depend on Steam. You can't even argue that it cuts down their user base, as Steam has the biggest user base in the industry - not being on Steam actively do that.

Sadly, idealism will only take you so far.
I will take this a bit out of context - you can either choose to use a tested and functional API for your game, or you can make your own, not as good one. This move will force you to cut a lot more corners. Do tell me which one of these seems more professional to a customer:
a) He wants to play with his friends, so he creates an internet game. His friends try to locate him on a server list, but can't. Of course, that's just about the extent of what the usual user can do, so they don't play
b) He wants to play with his friends, so he creates a lobby, sends out invitations and the game works.

Fenixp: As I said, I don't consider a project tied to one distributor because of side technical reasons to be professional. That's about it. Professional project should avoid such lock-in pitfalls.

No idea about Shogun: Total War or Dishonored whatever those are. If they are Steam only - too bad, I'm not using Steam anyway, and such requirement to use Steam to use their games is insulting actually.

I'm not saying they can't use Steam - let them use all they want. But Steam only is not the same as using Steam as distributor in general. If their game can work without Steam and can be distributed by others - fine, even if Steam ships it as well. If not - it's not a good game.

And that's also part of why it's unprofessional. Really it's their inability to make the game not depending on Steam excusing it with "you aren't our target". Whatever they consider is their business, I view it as poor development and management of the project.

Well, I take it you're not actually able to answer my questions. Shame that, I'm genuinely curious for an answer, as my experience with open source projects is limited and quite simply isn't as good as that with paid dependencies. So I'm going to extend them to everyone, if you're willing to read the previous posts I've made - don't worry, I won't attack you for your opinions, I'm actually quite curious, especially on the support front.

Fenixp: I see no point in questions like "how are you going to implement XYZ if not using Steam"? They aren't any better than questions like "how can you make a game for Linux users since it differs from Windows?". You design the solution and implement it, that's it. Did anyone declare Steam an absolute base of any network game development? I guess all developers who make MMOs not tied to Steam didn't pay attention to that "wise" assessment.