Boring Metablogging, Part Two

I try to not blog about blogging. Metablogging is boring. The last time I blogged about blogging was on the subject of "Can I take your blog post and republish it?" My answer then was "yes... but". That is, yes, but please tell me, please do not maliciously quote me out of context, please link back to the original, and please don't expect me to correct errors in your copy.

In the world we live in now, a world with various ways of poisoning search engines, that seems a bit naive. Of course, there's little I can do to stop anyone from copying everything I write onto their own servers and then tricking search engines into sending clicks their way, so saying "please don't" is unlikely to help.

My position on blog post republishing is thus basically the same, though I would add one more caveat to that list.

Everything I write at work is copyright Microsoft Corporation. I am not a lawyer of any stripe, certainly not a copyright lawyer, and though I certainly am a Voice Of Microsoft on the subject of the C# compiler, I am definitely not the Voice Of Microsoft on the subject of copyright law.

I write this blog so that the information in it can be disseminated as efficiently as possible to those people whom it helps in their jobs; I appreciate that the whole point of syndicated content is that it can be picked up, aggregated, and republished, and I certainly do not want to work against that or discourage the benign use of such services. But I also do not want to create additional work for myself or liabilities for others. So, please use good judgment and be willing to take responsibility when you disseminate someone else's copyrighted content.

I'd also like to contrast republishing of blog posts with publishing of private emails. This comes up because I recently dashed off an email to a customer in which I made some brief, off-the-cuff comments about some proposed C# language features that had been mentioned on a third-party newsgroup. The customer asked if he could post my emailed comments onto said newsgroup.

I said "please do not", and here's why.

First off, my comments were brief and off-the-cuff. I take a fair amount of time with blog postings to make sure that the prose is polished, the content is complete and accurate, the order in which topics are presented is sensible, that the whole piece flows well. I don't always succeed, but I try. In short, I apply a lower standard to brief emails than I do to public, archived, in-the-world-forever postings.

Second, by allowing the reader to post on my behalf, I would be encouraging him to indulge in hearsay. I have seen my fair share of internet newgroup flame wars, and believe me "Oh yeah, how do I know this is really from a guy at Microsoft?" is an argument you don't want to get into.

Third, all the copyright issues which I mentioned above come up again, even worse. The various third-party discussion sites all have their own policies about who owns the content posted on them and that is just a mess that I do not want to get into or encourage anyone else to get into.

Fourth, by posting my comments in a forum that I don't have posting access to, I have no ability to respond there to further questions, criticisms or follow-ups. I have no ability to correct mistakes in my posting or to add explanatory details should something prove confusing. I have no ability to engage in conversation. I likely have no way of even being informed when a response is made. This sounds suspiciously like its making more work for me in return for less value. It sounds like a good deed once more failing to go unpunished.

So: if you've gotten an email from me and you think that it might make a good newsgroup posting, here is what I encourage you to do:

  • Send me an email suggesting that I write the email up as a blog post.
  • After I do so, publish a link to that post in whatever newsgroup you like.

If that's the way it goes then all the objections disappear. I am publishing Microsoft-owned content written by me on a Microsoft-owned site, so there's no copyright issue or hearsay issue. I can make corrections, additions, updates, at will. I can be as prolix as I want to be on my own schedule. I can get reader comments and (time permitting!) respond to some of them. (I have gotten over five thousand comments on this blog; I cannot possibly respond to them all.)

OK, that's enough metablogging for the next four years or so. Back to some fabulous adventures!

Comments (8)
  1. Ilya Ryzhenkov says:

    This is pre-emptive for C#4 postings? 🙂 Hope to see some soon.

  2. ffpf says:

    That’s not what you said on <insert random forum here>. 😉

  3. PiersH says:

    speaking of c# 4.0, i’d love to be able to use the ‘readonly’ modifier on the set part of automatic properties:

    public string Name { get; private readonly set; }

    there’s probably an extremely nuanced reason why this isn’t available in 3.0. i’m just not smart enough to see it.

  4. Matt says:

    Piers, that code would then involve quiet a complex syntactic transform since the current compiler does literally generate properties and a field the assignment code in the property would violate the readonly semantics on the instance field.

    Also any use of property initializers would be invalid (since the contract of readonly is that the field value is not modified post construction.

    Sub classes could invoke methods within their constructors which expected that field to be fixed, but it would not be since the initializers happen after the sub classes constructors.

    An option for you instead is to use a public readonly field. Then assignment within the constructor is allowed, obviously this is not ideal.

    as an aside you didn’t used to work in nottingham did you?

  5. Aaron G says:

    How can you have a "readonly set"?  By definition "set" is a write operation.  A read-only property should not have a setter at all, except in the one case where it might be set internally, hence the "private set".

    I guess what you want is a read-only property with a value assigned in the constructor, like you can do with a readonly public field, but since that’s going to save you all of 1 line of code, it seems like much ado about nothing.

    So, pedantic question for Eric: What’s the policy on publishing replies you make to comments on your blog?  Do they follow the same rules as full postings or off-the-cuff remarks?

  6. Eric Lippert says:

    > What’s the policy on publishing replies you make to comments on your blog?

    My suggestion is the same as for blog posts: "publish a link, not a copy".

  7. PiersH says:

    I was thinking that the following code:

    class A


    public string Name { get; private readonly set; }

    public A (string name)


    this.Name = name;



    could be translated into something like this:

    class A


    readonly string <Name>k_BackingField;

    public string Name { get { return <Name>k_BackingField; } }

    public A (string name)


    this.<Name>k_BackingField = name;



    The key here is the ability to state explicitly that the value is immutable, which offers all kinds of goodness:

    – it’s self documenting – clients of the class can see that the value’s never going to change.

    – it’s future proof – having ‘private set’ doesn’t prevent someone from breaking the constness later on.

    – there’s some optimizations that could be applied by the compiler and possibly the JIT.

    public readonly fields are no good, since you can’t change the ‘getter’ in the future without breaking the API.

Comments are closed.

Skip to main content