This is part 1 of a two part interview that we had with the founders of the Glimpse Project, Nik Molnar and Anthony van der Horn.  The reason for two podcast releases is that we had such a great conversation with them, it was very tough to find any bad parts of the interview, plus there were essentially two podcasts.  One about Glimpse and how it came about, and the other about the industry of open source.  In the first podcast, Nik and Anthony talk to us about what it was like to start Glimpse and what it takes to create a successful open source project.

If you are not familiar with Glimpse, it is an Open Source platform that aims to change the way we think about diagnostics and the frameworks we interact with. After releasing Glimpse at Mix11, Glimpse has become a tool that is used daily by tens of thousands of developers around the world. It is intended for developers who want to use a a client side diagnostics tool for the server side of their applications. It is often referred to as Firebug for the server.

Podcast: http://seriouslyopen.com/glimpse-with-nik-molnar-and-anthony-van-der-hoorn
Download: http://traffic.libsyn.com/seriouslyopen/2-glimpse-nik-molnar-anthony-van-der-hoorn.mp3
iTunes: https://itunes.apple.com/us/podcast/seriously-open/id636361747

To talk about and promote Open Source .NET software development to encourage more participation.

It occurred to us while we were talking about the setup of the podcast, such as name, logo, topics, etc, that we should just record it.  And make this podcast process as open as possible, just like a real open source project.  We decided on the podcast that we had the following outstanding issues for the podcast that we needed pull requests from the community for:

1. Name
   Should be available both in .com and twitter
2. Logo
   Dependent on #1 being done.
3. Intro and exit music.
4. A 3rd podcast member.

If you can help us out with any of these issues will we take your suggestion seriously and incorporate them in.  The obvious outstanding and persistent issue that we will always be willing to accept is new hot .NET Open Source projects that you would like us to interview the founders of.

Without any more setup, here is our first podcast in hopes of many more if it is well received.

Please use the commenting in my blog to leave any feedback, as we get the above issues resolved we will try and find a better home for what we are doing.

I am writing this post, because even after one year I am getting very passionate comments on one side of the issue or not, people don’t seem to take a middle road on the strong naming issue. If you don’t believe me take a look at the comments.

Lucky for us, most developers who choose to strongly name their assemblies now are using a versioning mechanism that reduces the chances of breaking referencing assemblies in NuGet.  This “new” versioning technique is actually a non-technique.  Let me explain, instead of changing the version of the assembly with each release, you leave the version of the assembly set, until it is necessary to communicate a major release.

Lets look at JSON.NET again as our standard bearer.  Mostly do to the fact that it is the most widely used strongly named assembly in NuGet.  Since I last wrote my post almost a year ago, 11 releases have been made, however none of those releases caused breaking changes for any of the NuGet packages that referenced a 4.5.x version when built.  You may ask, “So what changed?”  As I alluded to previously the answer is “Nothing.”  NuGet still functions as it did a year ago.  Strong naming still functions as it did a year ago.  .NET assemblies still function the same as they did a year ago.  The strongly named version of Newtonsoft.Json.dll did change either across those 11 releases, it has remained constant at 4.5.0.0.  And that last thing is exactly what was needed to settle down all the referencing problems in NuGet.

As I talked about in my previous post the main difference between strongly named assemblies and plain assemblies is that when you strongly name an assembly the versions have to match for any referencing assembly, for plain assemblies there is no requirement.  If you put out a new release of a strongly named assembly and don’t change the version, the assemblies that reference it don’t know the difference and are happy to keep using it.

At the time when I posted my previous post, I hadn’t realized that James Newton-King had changed the policy to what I had described above, which is commonly referred to as SemVer.  He pointed this out to me in the comments.

FYI I discussed strong naming a couple of weeks ago –http://james.newtonking.com/archive/2012/03/20/json-net-4-5-release-1-iso-dates-async-metro-build.aspx

No one seems to have read it.

He was right I didn’t read it and that was a failure on my part.  The only reason I bring this up and mention him in this post, is because while I don’t owe him an apology for speaking my opinion, I do have to apologize for using his project as an example of a wider spread problem in the industry at that time.  Projects like JSON.NET are often surrogate children to their owners, and to call out another person’s child in such a public way isn’t fair, so I apologize for that.

My stance on Strong Naming assemblies has softened a little over the past year, mostly due to the fact that it isn’t causing me as much greif as it use to.  I still think it is a plague on .NET developers, unwittingly forced down on high from a VP who read a white paper from 2001.  However, I typically take the stance of, if it doesn’t effect or slow down me, I am going to stay hands off on what other people do.  And right now that is the case.

In honor of the Microsoft MVP Summit going on in Seattle right now, we are offering every person who signs up this week, 5 hours of complimentary compute time for running all your CRON jobs.

Signup here: http://executify.com/signup

After you sign up for your account be sure to checkout our documentation on creating your first CRON job in Executify.

When it gets to the point of out right copying of whole files it becomes a different story all together.  And that is what I am addressing today.  I should start out by saying that Datastax is a great contributor to open source software, and has provided the Cassandra community with a great amount of free docs and tools, and is one of the primary drivers behind recommending the FluentCassandra library to clients.  I wish that is where we could leave it.

One of their developers decided to take some shortcuts and started copying FluentCassandra without attribution and passing the work off has his own. Everybody has deadlines and I understand that, but it takes a certain kid of malevolence and disdain for open source software, to out right copy certain parts of a competing code bases code for the expediency of getting your own out to market.

The developer who did this, Pawel Kaplanski, contributed a couple issues and some minor code that ultimately had to be rewritten to FluentCassandra back in September 2012.  You can see that he does work for Datastax here and that the only thing he has done for open source software ever to contribute a few minor things to FluentCassandra over a 3 day period in September. (side note: I would hope that a company like Datastax who loves open source software, would hire developers who love open source software, however that doesn’t appear to be the case with Pawel who seems to only troll for code to make his day job easier)

Pawel was first introduced to me back in September by Michael Figuiere. In the email Michael was explaining to me that Pawel was going to be helping me out on FluentCassandra while working on their own client library.  Which was wonderful news for me, because I always appreciate help, I thought this was a win-win for everybody involved. But as you can see from the above Github interactions, Pawel didn’t quite live up to his end of the bargain, and as I will show next in seemed to only be a win for Pawel.

So lets get down to the dirty stuff.  Which I have started to track in an issue on FluentCassandra.  The first and most egregious copying of code, and the part of FluentCassandra that has literally taken many many weeks of my time, over the past year, in tweaking and getting just right is the LINQ Expression Evaluator.

As you can see in this picture the white spaces in the indicator on the left hand side is code that was copied.  These pieces of code contain the exact method names, program code, positions, and everything, so it is undoubtedly copied as a whole and then tweaked for his own needs.  This is just lazy and dishonest.

There are others too, notice any similarities here:

https://github.com/datastax/csharp-driver/blob/28d8958873f55727bf515cf97b32c9cbfa31af9f/Cassandra.Data.Linq/CqlQueryEvaluator.cs
https://github.com/datastax/csharp-driver/blob/28d8958873f55727bf515cf97b32c9cbfa31af9f/Cassandra/GuidGenerator.cs
https://github.com/datastax/csharp-driver/blob/28d8958873f55727bf515cf97b32c9cbfa31af9f/Cassandra/GuidVersion.cs
https://github.com/datastax/csharp-driver/blob/28d8958873f55727bf515cf97b32c9cbfa31af9f/Cassandra/DateTimePrecise.cs

No attribution at all for our hard work:

https://github.com/managedfusion/fluentcassandra/blob/master/src/Linq/CqlQueryEvaluator.cs
https://github.com/managedfusion/fluentcassandra/blob/master/src/GuidGenerator.cs
https://github.com/managedfusion/fluentcassandra/blob/master/src/GuidVersion.cs
https://github.com/managedfusion/fluentcassandra/blob/2c77dfca83891a9559e14a2b58797095c0486050/src/System/DateTimePrecise.cs

The last one is the most interesting because it dates when he copied the FluentCassandra source code as somewhere between August 25 and September 6.  Which line up nicely to his 3 days that he looked at FluentCassandra.  I know this date range because I removed DateTimePrecise from the code base on September 6 because it had a nasty bug in it.

To be clear I am just very irritated that Datastax promised some help to FluentCassandra and the only help we seem to have gotten was a developer who decided to steal our code and not contribute anything back.  And the two bugs that Pawel opened on FluentCassandra were bugs that he fixed in his own copy of the source code, but couldn’t be bothered to contribute back to FluentCassandra.  That takes a real set of brass ones to be that blatant.

There is one bright spot and really all that I ask for, developer kcieslinski does actually attribute FluentCassandrawhen he copied the BigDecimal code.

That simple one line is all that I ever ask for.