It’s time for your first PR


If you’ve never issued a PR, now, it’s the best time to do it for the first time.


If you think that issuing a PR is not for you, please read the following Whys and issue your PR then 🙂


The weakest argument goes first. How cool is to say that I’m the contributor to XYZ. Open Source Software has a strong position in developers’ minds so if you’d like to impress someone for any reason, this can be the way.

Fear of being ridiculed

When you issue a PR, it is reviewed. You may consider sending a PR to do not get ridiculed (in Linus style). The thing is, that laughing at your contributors doesn’t pay off. From a maintainer perspective, if people drop off, you have more work to do, as no one is willing to handle registered issues or make meaningful changes on your own. Maintaining a good relationship with contributors is a thing that works the best.

Learn from the best

Sometimes you’d like to ask a famous developer about a possible improvement to their product or just verify some technical thought. How about being given their full attention and learning some of their expertise? PR is a great way to get both at the same time. Just write your idea in the code instead of a vague human language and share it as a proposal. You’ll get it reviewed it for free and your code for sure will be a beginning of a meaningful discussion.


If none of the above work for you, think about your CV and the fact that asking for OSS contribution references is getting more popular this days. Your changes to publicly accessible projects are the best way of showing your potential.

If you’ve never issued a PR, it’s the best time to do it for the first time. Just book an evening or two and make the positive impact on the OSS environment.

Wire improvements


This post sums up my recent involvement in the Wire serializer being built by the Akka.NET team. It was an interesting OSS experience. I’m glad that I could improve the performance of this serializer .

Box me not

The initial design of constructing a serializer of a complex object was based on emitting a pair of delegates (serialize, deserialize). Let’s consider deserialization:

  1. Create object
  2. For each field:
    1. Use the following method of a ValueSerializer:

      public abstract object ReadValue(
         Stream stream, DeserializerSession session)
    2. Cast to the field type or ubox if the field is a value type
    3. Load the deserialized object and set the field.

The problem with this approach was manifesting for classes with many primitive properties/fields the cost of boxing/unboxing might be quite high. On the other hand, one couldn’t be calling a method returning a common type without boxing for value types. How would you approach this? My answer was to move emitting point 1 & 2 to the value serializer and provide a generic implementation for this emitting in the basic class. That allowed me to customize the emitting for primitive value types like int, long, Guid still preserving a possibly bit less performing generic approach.

After the change and delegating the emitting to the ValueSerializer class, it was given two new virtual methods with their implementation using boxing etc, but leaving much more space for special cases

public virtual int EmitReadValue(Compiler<ObjectReader> c, 
   int stream, int session, FieldInfo field) 
public virtual void EmitWriteValue(Compiler<ObjectWriter> c, 
   int stream, int fieldValue, int session) 

Call me once

Wire uses a BCL’s Stream abstraction to work with a stream of bytes. When using a stream, a conversion to primitive value types sometimes require a helper byte array to get all the data in one Read call. For instance, a long value is stored as 8 bytes, hence it requires an 8 byte array. To remove allocations, during serialization and deserialization, a byte chunk can be obtained by calling GetBuffer method on the session object. What if your object contains 4 longs. Should every serializer call this method or maybe it should be called once and the result stored in a variable?

I took the second approach and by removing this additional calls to GetBuffer was able to squeeze again a bit more from Wire.

Summing up

Working on these features was a very pleasant experience. It took me just a few evenings and I was able to make a positive impact. And this is really nice.

RampUp journey ends

My RampUp project has been an important journey to me. I verified my knowledge about modern hardware and dealt with interesting cases writing a really low level code in .NET/C#. Finally, writing code that does not allocate is demanding but doable. This journey ends today.

RampUp has been greatly influenced by Aeron, a tool for publishing your messages really fast. You can easily saturate the bandwidth and get very low service time. Fortunately, for .NET ecosystem, Adaptive Consulting has just opened an Aeron client port here. This is unfortunate for RampUp as this port covers ~70-80% of RampUp implementation. Going on with RampUp would mean, that I need to chase Aeron and compete somehow with Aeron.NET to get an .NET environment attention, and in result, participation (PRs. issues, actual use cases). This is what I don’t want to do.

RampUp source code won’t be removed as still, I find it interesting and it shows some really interesting low level cases of CLR. I hope you enjoyed the ride. Time to move on 🙂

We accept pull requests

There are many protocols of collaboration. There’s famous C4 from 0MQ & others as well. Sometimes a project lives without collaboration rules being explicitly stated for years and can be successful. Sometimes it can suffer from bad assumptions collaborators made when they decided to invest their time in a project. To lower the possibility of any unhealthy friction, I’ve decided to write at least some bullet points for RampUp and created a simple (I’ve just been sent the very first PR for RampUp :D).

The main issue I wanted to address was that ‘I accept pull requests’. This topic is discussed over and over again and can be described in a following way: .NET devs are not willing to collaborate and rather than providing PRs they just blaim/complain etc. The landscape is changing now and everyone involved in .NET Open Source can feel it for sure. More PRs is being issued, the engagement, so strongly needed is shifting towards an actual participation rather than poking. It doesn’t matter if you provide a new feature and rather than spending days on drawing UML you sketch it and issue a PR or if you spend one additional hour of your debugging time, distilling a PR reproducing a bug you’ve encountered. That’s what real involvement is. It’s not about talking, it’s about making things. Even if a PR is rejected for whatever reason, you learn a lot, you really participate and get a real feedback about your work, not your cheap talk.

I really hope that the new wave of OSS is coming. In that case, let’s swim with the tide.

Open Source (almost) everything

Your software problems are not unique.
You don’t have time and money to maintain the whole toolkit you need.
You may be not smartest in the domain of the problem you’re trying to solve.

These are simple facts and you should accept it. What can you do about it? You can open source some parts of the solutions you deliver! Don’t think about a bank’s transactional system, or some high security fragments. Consider closed pieces, parts which deliver one thing (libraries). Put them on GitHub, or Codeplex or whatever. What you get is a chance of having your issues fixed by some other people. The another advantage of open sourcing some parts is paradigm shift. Now you have to combine, compose parts rather than getting your hands dirty in a ball of mud. What about your business, what about competition? At most they have a few of your tools, but the whole knowledge, how to assemble them stays in your company, and that in my opinion is the future of software development.


I had an idea about querying and projecting over big streams of messages serialized with Google Protocol Buffers. If one needs only a few fields to his/her projection, why don’t make it implicit and prepare an optimal way of deserializing only these fields? That’s the way Protobuf-linq has been born. It’s simple, fast and eager to help you iterate over big streams of data.
Check it out!