A line in the sand

Just recently I read Rework again on my kindle as this book really resonated with me at the time and I thought it was about time I read it again; the book is from the guys at 37 Signals aimed at people starting a business. When I got to the section titled "Draw a line in the sand" I realised that this book is also appropriate to anyone who is thinking of creating/managing or getting involved in an open-source project/product; I am not talking abut flinging up some source code or sending a pull-request and going ta-da, I mean potentially committing several hours per week over many months if not years.

This particular section in the book talks about drawing a line under what your product does and doesn't do and asks what are you willing to leave out to keep the product true even if it means some of your customers don't get the features they want. We see this far too often with great commercial products that start to become bloated as they try to chase every possible sale with more and more features that fewer and fewer people use and with an open source project I think it is all too easy to fall into the trap of fulfilling each feature request because you may think "great, someone wants to use my project but only if I do X, Y and Z by next week." I've had this scenario many times over the years with OpenCover and I have to decide whether or not to implement a feature (also do I have the time to do it and how will I support it) so I've had to draw a line in the sand many times using the following criteria "do I need it". It really is as simple as that, if I don't need it myself I am not going to spend my time on it. Now that doesn't mean I will reject code from other developers that meets their needs and enhances the product (especially since they have spent the time and effort to share their work, that would just be churlish) but I have to draw a line under what I am willing to commit to in order that I enjoy working on the project and not feel I am working for someone else, for free.

One feature I've never implemented is creating a UI for OpenCover even though PartCover (OpenCover's predecessor) has one, as I felt the UI provided by ReportGenerator was awesome and did the job perfectly that I felt anything I did implement would always be inferior. More recently another UI related feature that I didn't implement due to lack of personal need was "Visual Studio Integration", I use ReSharper as a test runner and I don't actually look at the code coverage until I think I have all the right tests in place; this keeps me honest, I believe, in that it I try to write tests for the code rather than tests for the coverage. However some members of the community wanted one and went and developed an extension themselves, actually there are two extensions currently in development OpenCoverUI and Testify which I think is great.

Another example is a feature that has sat on backlog for over 2 years "Support Coverage of Windows Store Applications on Windows 8". I know how to do it, well I have some guidance from David Broman at Microsoft so I know where to start, but I don't actually need it. When I write a windows store or phone app I put the majority of the code in an assembly separate from the UI and use unit testing to get the coverage. I don't care that much about coverage from integration testing as I find the results I get from unit testing far more valuable. Now I know people sometimes in the pursuit of 100% coverage want to get coverage results from integration testing and have some automated UI tests etc and OpenCover will usually support them. Hooking into windows services was implemented by someone who needed that capability, I tested and accepted their pull-request but I've never had to use the capability. IIS integration is tricky, I always use IISExpress myself if I need to go down this path, but the guidance was provided by someone who needed it themselves and so I shared it. One day I may need to implement this particular feature so I am not going to take it down and perhaps if someone wants it beforehand the guidance is on the issue if they want to implement it; though there has been no request for it though either.

I could list other sections that seemed related and applicable to open source projects e.g. "Be a curator" or "Don't be a hero", but frankly I think I would just be listing the entire book contents, best you get Rework yourself and read it and then read it again; each time I read it I get something new from it.

_{Image - Mandala, Coney Beach 4 via photopin (license)}