Visual Studio Team Services (VSTS) offers a suite of DevOps capabilities to developers including Source control, Agile planning, Build, Release, Test and more. But until now all these features require the user to first login using a Microsoft Account before they can be used. 

Today, we’re starting a limited preview of a new capability that will eventually extend the powerful features of VSTS to the open source community. Starting today, we’re working with a small number of open source projects to begin testing this experience in beta before rolling it out to a wider set of projects. In this blog post, we want to give you an early look into what this new feature does and why we’re building it. 

Introducing Public Projects in VSTS 

With public projects, users will for the first time be able to mark a VSTS Team Project as public. This will enable anonymous users to be able to view the contents of that project in a read-only state enabling collaboration with anonymous (un-authenticated) users that wasn’t possible before.  

Anonymous users will largely see the same views as authenticated users, with non-public functionality such as settings, or actions (such as queue build) hidden or disabled. As we continue to work on public project support we will be improving the views, especially for un-authenticated users. 

How does it work? 

In this initial preview, when you mark a project public, the Build, Release, Git repos, Dashboards and a subset of Work will appear visible to the anonymous users visiting your project through a publicly accessible URL that does not require any authentication.  After working with some projects to get early feedback, we plan to hopefully make the full contents of a public project visible, including additional areas such as Test and Package Management, allowing users to host NuGet, Maven and npm feeds for their projects’ CI builds. 

Public projects are an entirely opt-in experience in which account administrators have full control over who can enable this functionality. The default for existing VSTS accounts will be private; the account administrator will need to first enable Public Project support for the account and then specially set an individual project to be public. 

A practical example: .NET Core CLI 

Supporting open source development is one of the most compelling scenarios for public projects.  A good example is the .NET Core CLI.  Their source is hosted on GitHub and they use VSTS for their CI builds. However, today if you click on the build badges in their readme, unless you were one of the maintainers of that project, you will not be able to see the build results.  Since this is an open source project, everybody should be able to view the full results so they can see why a build failed and maybe even send a pull request to help fix it.  

Thanks to public projects capabilities, the team will be able to enable just that experience and everyone in the community will have access to the same build results, regardless of if they are a maintainer on the project or not. 

Road Ahead 

We are incredibly excited to be able to offer the power of our cloud hosted Mac, Linux and Windows build servers to the world, and make it easier for developers to create an automated build pipeline for their projects. For open source projects, the build and release capabilities of VSTS’s and support for public projects will be a great complement to functionality in GitHub, where many community developers collaborate on projects. 

As we strive to get the experience right for the community, we’ll be working with a small group of open source project maintainers before making this functionality available to the rest of our community. Following this initial testing, we’ll share more details which will include updates to our license and pricing to enable project members working on open source projects to use VSTS for free.  

To apply to sign up to the early preview, tell us about which projects you want to use this for by emailing our team at: vsts-public@microsoft.com.