More Loupe is Now Open Source

Where is Loupe Going with Open Source?

As part of Loupe 3.8 we’re migrating our internal SCC from TFS 2013 to Git.  This has given us a golden opportunity to reassess, project-by-project, where should this project live?  Should it be part of our closed source or open source portfolio? It’s a great time for Open Source in .NET - most of the core framework and big parts of the ecosystem like Entity Framework are now out there, actively taking third-party contributions.  We decided our goal should be to open source as much as possible with a few guidelines:

  • If people modified it, they’d have to be able to use their modifications with the rest of Loupe unchanged.  This means it should only depend on our public APIs.
  • If it’s open source that we modified then it should be separated out and published, giving back to the open source community from which it came.

In short, everything we’ve written that uses our public APIs is now open source, including:

The ones marked with an asterisk (*) were previously open source, the rest are new as part of this latest push.

We’ve also published our modified version of SourceGrid which is used in the Loupe Live Viewer.  This is an existing open source project that we did a range of changes to.  While we think few people would be interested in our changes (they were needed to support multiple UI threads in the same application domain) it fit our criteria so we’ve published it as well.

Where Does Loupe Open Source Live?

CaptureWe’ve published each of these items out on GitHub as their own repository.  Each repository is self-contained, needing only NuGet packages to other dependencies.  We’ve reviewed each project to make sure there are build instructions, usage instructions, and link to other useful sources of information.  In short, if you want to modify one of them to your own ends - have at it!  If you’re curious how we’re doing something, you can find it there.

If there’s a problem and don’t want to send us a support ticket you can open an issue on GitHub or even branch the code and send us a recommended change.  If you think this is an empty threat, it’s happened already to the agent for ASP.NET Web Forms and the agent for Entity Framework.

More than a Shadow Copy

If you take a look at the repositories right now you won’t see much history.  This is because these are taken from our Loupe 3.7.2 baseline.  From here on out, the Master branch in GitHub is connected to our build process and in turn feeds NuGet.  That means when we want to make a change it’ll look just like if anyone else did - we’ll make a branch, do the change, and do a pull request.

You can see more evidence of this with the Loupe Agent for JavaScript.  We haven’t published this yet - it’s still in initial development and testing - but we’ve pushed it out to GitHub.  This is probably our first project that didn’t originate in our TFS but instead went straight from Dave’s computer to GitHub to the rest of the team.

As part of the build process that goes to NuGet we are generally signing the assemblies with the Gibraltar Software Strong Name Key.  This is mostly because signed copies are needed for some customers but it also gives customers a way of ensuring they’re using official binaries if they want to.

What Does This Mean for Me?

If you’re using any of the items we’ve published to NuGet and in general don’t feel a need to modify them, then nothing - just keep getting new versions from us as you always have.

If you run into any problems with any of these items you still contact us for support just like you always have - they’re fully supported by us, documented by us, and we’ll be maintaining them as Loupe evolves.

We’ve just opened the tent so folks that want to can inspect, modify, repurpose, extend, adapt and generally play around with the code.

What about the Rest of Loupe?

The core of Loupe - Loupe Desktop, Loupe Server, and the Loupe Agent itself - are remaining closed source.  We are evaluating open sourcing the Agent as part of Loupe 4.0, but there’s a lot of work we’d need to do to make that happen: There are some bits we don’t have the right to publish and we want to refactor the codebase to make it much simple to build and maintain.  We’re also frankly new to managing open source projects and we want to walk before we run with the key linchpin of the whole system.

There are a set of libraries - notably the various add ins we ship - that meet our overall criteria for being open source but can’t be reasonably changed by anyone else because they’re also using internal APIs.  We’re hoping to refactor them as part of Loupe 3.8 so they can be published as well.

Stay in the Loop with Loupe

Subscribe below to receive additional Loupe 3.8 updates, design artifacts, previews builds and special offers.

Rock solid centralized logging

Unlimited applications, unlimited errors, scalable from solo startup to enterprise.