Editor's Note

Thinking Outside the VS Box

Editor in chief Patrick Meader explains why the magazine (generally) forbids discussion of third-party products, while allowing authors to discuss non-Visual Studio-specific tools from Microsoft.

Paul Levoy of Ontario, California, wrote me recently to question why the magazine generally discourages authors from using third-party products in the magazine's how-to articles, while at the same time allowing authors to discuss a wide variety of Microsoft tools and services that fall outside the literal province of Visual Studio. Wrote Paul:

I've noticed that you almost never run how-to articles that depend on non-Microsoft products, yet you frequently run articles that cover such non-Visual Studio products as Windows (in all its various incarnations), SQL Server, FxCop, SharePoint, and so on. Why are you willing to make these exceptions for Microsoft products, but nothing else? For that matter, there are many other .NET languages—why cover only VB .NET and C#?

Your assessment about the magazine's coverage is fairly accurate.

VSM strictly forbids the coverage of non-Microsoft products (aka third-party products) in its features and columns; at the same time, the magazine allows and even encourages its contributors to cover topics and tools that rely on tools from Microsoft other than those that ship with Visual Studio.

We forbid the use of third-party products in the features and columns because we as a magazine want to maximize the potential reach of any given article. Were we to allow authors to rely on third-party solutions in the magazine's how-to articles, we would automatically limit the appeal of those articles. Even if you were able to download a free or trial version of the component used, you probably wouldn't bother to do so, according to reader surveys and polls we've conducted over time. Plus, we'd be in the position of choosing which third-party tools to allow or not allow, and that would create a host of political issues, which leads directly to another concern: It's critical to us that we avoid even the appearance of impropriety. Running articles about third-party products (outside the First Looks and reviews sections) would lead many readers to wonder whether a given company's products were covered only because that company bought advertising in the magazine. Our editorial independence is important to us; it is important it be preserved, not just in fact, but in appearance.

(As the editor, I do not know which advertisers have chosen to participate in a given issue until I see the ad index, which is prepared at the last moment, long after the articles have been written and edited.)

When I say VSM strictly forbids the use of third-party products in its articles, what I mean, of course, is that the magazine strictly forbids their use most of the time. For example, Oracle is an extremely popular database server among our readers, and we occasionally run articles that feature solutions that rely on Visual Studio and Oracle. Similarly, we've covered open-source testing tools for which there aren't (or weren't at the time) widely used alternatives that shipped with the Visual Studio tools suite.

So, you might wonder: Why the double-standard? Why do we cover Microsoft tools other than Visual Studio? It's because VSM is a magazine targeted at professional Visual Studio developers, and there is a high percentage of Visual Studio programmers who also rely on SQL Server, and of course, various flavors of Windows. Indeed, the work people perform in Visual Studio is often inseparable from the operating system or the database server used in conjunction with most Microsoft-based apps. Excluding these applications would make it almost impossible to provide you with real-world focused examples that are the magazine's bread-and-butter.

The baseline we use as a magazine to determine whether a given product can be discussed in an article is whether it is included in Microsoft's MSDN developer subscriptions. Of course, not every product included in an MSDN subscription is applicable to us; article subjects still must meet the first requirement of appealing to a (potentially) broad cross-section of readers.

So it is that the magazine covers only the C# and VB .NET programming languages in Visual Studio, while offering only rare pieces on the .NET version of C++ or other .NET-based languages. Nearly all of VSM's readers tell us they use VB .NET or C# primarily, and many use both. For those few who use some other .NET language, the principles discussed in articles based on C# or VB .NET usually translate to other languages, as well.

Talk Back: What areas of coverage would you most like to see going forward? Write us at [email protected].

About the Author

Patrick Meader is editor in chief of Visual Studio Magazine.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube