Our story about delivering open source software.

By Cyprien ,

It's been a few months since we launched our first Visual Studio Team Services Extensions. We are thrilled to see you already love them with a bit more than 1 thousand downloads and pretty good feedback and ratings. Microsoft also has featured two of our extensions and it makes us proud.

Party Time!

Let's talk about why we've done that, what we learned and what's next?

Open source commitment

When we started our work with VSTS we often ended up copying and editing powershell and gulp scripts from our own projects. This was quite terrible as we had a lot of drift between our various customers and projects. I remember this days were Adrien and I used to spy our respective commits on different project to keep track of recent script improvements. Least we can say, this was a bummer.

One of the key motivation behind our extension was to remove scripts we were copying from project to project and ensure we could rely on easy to use updated tasks across all of our projects.

We now rely heavily on them when designing software factories for our customers, or building software. So, we needed a way to share this work between them. It was also very important to reassure our customers about the fact that our solutions are gonna last and don't rely on a tricky script written by one geek which can't be maintained once he is gone.

We are also deeply involved in the xplat mobile development and we currently work a lot with Xamarin and Cordova. This means we are running builds on MacOS.

We came up with the following constraints :

  • We need a solution we can share between us and our customers without raising any IP concerns.
  • We need it to be easily updated if possible without thinking of it.
  • We need to run cross platform
  • Usage, Development, contribution and publication should be easy.

It was pretty obvious that one good way to address some of those needs was to make our software free and open-source. That way, anyone can benefit from what we do, every customer benefits from improvements we make and we benefit from the community PRs and feedback.

What have we learned?

After a bit more than a semester running those vsts extensions, and two years working on some other projects, we've learned quite a few things.

The phony syndrom

When we first started this adventure we had some doubts. Is it the right way to address our issues. Are we doing it right? Why would someone, who doesn't know us, trust us and our work? Are we legitimate to do this?

And I must confess that we were crippled by doubt and our extensions stayed private quite while despite being mostly ready. I don't know where this comes from, but it is scary to actually show our imperfect and under development code to the world. Anyone can judge!

The thing is you have to overcome those feelings, what can really happen? Nothing bad actually, you may have some unfriendly feedback but most of the time, people will be thankful for what you do. Actually, feedback, good or bad will help you thrive.

This Phony feeling is actually quite common in our line of work and I think it somehow gets in the way.

Everything takes time

Building quality software, even simple things like those extensions takes time. You have to prioritize things.

Getting to the point where everything has tests (unit, behavioral, integration or whatever) and you can call it a v1 is actually a pretty long journey.

By doing it ourselves, we now look at others products roadmap, bugs and priority with a more gentle eye.

The Javascript syndrom

Visual studio is not the only area where we have been working on open source software. We are working hard on some .Net Core and Ionic libraries.

In fact, when we started it was alpha time for .Net core, and no one was supporting it. We then decided to open source this without necessarily realizing the amount of work required to make all those live. But since then, .Net core is actually becoming a thing and more and more library support it. It makes some of our libraries look like Yet Another Fucking Library Doing A Shitty Job At X Subject.

And if there is one thing we don't want is reinventing the wheel for just the sake of doing so (despite having a good excuse for it, we've done a bit of that). Moreover, we don't want for nuget to become another npm like repository crippled by countless shitty forks and hardly maintained libraries doing the same things. So the best way to avoid that is to start sweeping our around own front door.

As we are going in the process of documenting, what we've done we are questioning the very existence of each one of our libraries and we already plan to iscontinue some of them in favor of contributions to more mature libraries we've identified. The idea is getting the most out of our energy and really contribute to a better .Net ecosystem**.

Support

Support is definitely the cornerstone of any product, even a free product like ours.

We provide community support through Github issues. So far, we are pretty satisfied of our job, we've been able to answer and resolve most requests in a timely fashion.

We are struggling with some more time consuming requests though. For instance we have some people requesting new features, we don't currently need ourselves. While we would be very happy to address them, we actually have to be realistic and most of the time keep them in the backlog with a PR Welcome flag.

We do not advertize any paid premium support at the moment (but you can always reach out to us). Paid support and buy us a beer is something we are currently thinking about. Making some money out of it would actually help us spend more time on making this great!

Contributing etiquette

Through our various open source projects we already received a few pull requests. We definitely consider it as a bliss and as one of the highest form of recognition or reward.

That said, we noticed that some people are sometimes pushing their needs, this sometimes leads to PR's we have no idea what to do with. They do not match our vision, quality standards or are to specific.

Regarding quality standard, we consider we can improve a lot, and we might have been privileging getting things done over making it perfect. This does not mean we should accept a bad quality PR. The basic idea is we would accept anything which would improve the quality and reduce the technical debt not the opposite.

Over the past three years we've been on both sides. We've been contributing to projects and accepting contributions. With this experience we believe that Open Source Contribution Etiquette is something extremely important. For instance it is almost always a good idea to open an issue and discuss what you want to do before pushing a PR.

Give, Give, Give, Ask

We definitely believe in this. This is a positive stance which can change your life. This might seem a bit pointless at first but trust us this is a path worth taking.

For instance, it took a while but we know start to see some rewards coming our way. Because of that, we also feel a bit more comfortable asking for PRs.

Everything seems easy when it's done, but trust us, it always require more work than one might think. When we face issues with a software it is easy to get trapped in the Dunning Kruger Effect and thinking we would do better in one night. But bringing a project to life is not only developing it, It is also, trial and error, testing, troubleshooting, packaging, branding, documenting, support and marketing.

So if you come somewhere and start asking or worse, ranting, there is very few chances you'll get anything. If you have no idea what you can give, then start by taking the time to provide constructive feedback and to follow the guidelines.

For instance this is disrespectful:
Mean behavior

And this better but still quite not there...
We don't know what to do with that

Let's be clear, we were prepared to see this, we have some experience with marketplaces. We also realise that .NET and Microsoft communities are pretty new in the open source ecosystem. By writing this, we hope we will contribute to relay some of the key things we need to build a better VSTS and .NET OSS community.

What's next

We have a few important things we are working on at the moment.

First thing : Documentation This is the most important part of any library or tool. We have decent documentation for our tasks, but we know we can do much better. We've already gathered some feedbacks on that matter and this is definitely something we will tackle soon.

Second : Roadmaps. We know that it matters to you. So we plan to go through every single repository and make sure we have proper milestones and labels. We will also mark some of them as deprecated. This way you'll be able to see where it's going.

Last but not least : Improve Contribution Experience. When we started building our extension we've also built pretty handy build scripts. They allow us to build, package and test extension easily. The thing is they were undocumented (it's getting better) and relying on submodules. This was a good start but this is not enough. We want it to be easy for you to contribute, so we will commit to streamlining the process.

Credits: