Oren Eini

CEO of RavenDB

a NoSQL Open Source Document Database

Get in touch with me:

oren@ravendb.net +972 52-548-6969

Posts: 7,640
|
Comments: 51,260
Privacy Policy · Terms
filter by tags archive

On API Design

time to read 2 min | 218 words

Krzysztof points out that Rhino Mocks has 26(!) methods to create various mocks.

I was very surprised to hear that, so I took a look, and he is right. The problem is how you think about those. Those 26 methods are only applicable when you count each overload as a separate method. Without counting the overloads, we have 10 methods. Then we have to consider options. In Rhino Mocks, you tend to have the following options: Create mock, create mock with remoting, create mock from multiple types.

That works to reduce the amount of options that we have down to about 4 different types of mocks that Rhino Mocks can generate. And you know what. Almost all the time, you don't need to use them. You only have to use DynamicMock and that is it.

Krzysztof suggestion would consolidate all the options to a far smaller surface area, but it would have several major issues:

  • Break backward compatibility - I am wiling to do that, but not without due consideration.
  • Break the documentation - See previous point.
  • Force the user to deal with all the options explicitly - "In your face!" API design, from my perspective. That would lead people to create utility methods over it, which gets us right back to all the method options.

time to read 4 min | 688 words

That was the topic under discussion in the first ALT.Net talks today. There weren't that many people at the talk, but it was very focused and useful.

In general, there aren't that many ways of funding OSS projects. Note that I am talking here from the perspective of the developers who does the actual work, and how they get compensated for their time and effort. This exclude reasons such as scratching an itch, or as a hobby.

  • The OSS work is useful for the day-to-day work of the developer. This is by far the more common model in the .Net world. Most OSS developers tend to do so because supporting the project supports whatever they actually trying to do.
  • Reputation building - being part of OSS project usually means that you get a good reputation as a result. This can be useful in getting a job, as an example.
  • Contracting / training / support. This seems to be a very common model in the Java world. There are only a few projects in .Net that are working in this approach.
  • Donations - nice in theory, doesn't work in practice.
  • Grants - someone who needs a feature pays for it being included. I had several leads in the past, but nothing that ever got to actual money exchanging hands.
  • Work for hire - Some entity that hire a developer to work on an OSS project. SvnBridge is a good example of that. The difference between this and the previous entry is that this is not necessarily something that the dev was initially involved at.

The session was focused on two subjects, how we can increase awareness, and how we can fund OSS projects. I think that the ALT.Net community is doing a lot best practices, approaches and techniques and the tools that can be used to support those. We recently had several articles in mainstream media about from members in the ALT.Net community, as a simple example. We can do more, like reaching out to the user groups, talking more about it, doing entry level tutorials, etc. But that is more related to adoption of OSS tools, not to funding them, which was the major topic for the session.

When we are talking about funding OSS projects, we have to make a distinction in what we are talking about. We can fund the OSS project itself, and we can fund OSS developers. I feel that a large part of the session was spent making this distinction.

The major difference is in what you are trying to achieve. I use OSS projects to help me do my work, I don't need them as a source of income. They are a tool. Getting paid to work on them is fun and would be lovely, but tat is not actually something that I spend a lot of time thinking about. A lot of the suggestions that we had at the talk all involved OSS developers making considerable investment in time, money & risk for the goal of furthering OSS development.

Sorry, it doesn't work that way. At least not for me. I am getting paid to write code. Incidentally, at this point in time I am actually getting paid to write OSS code, which I consider as a really nice perk, but not something that is in any way required.

When we are talking about funding OSS projects, I am actually thinking on the other side. Funding the project itself. however, is something that I would like to focus on. The best way I know of actually getting things done is to actually pay for it to be done. Working for free works if and only if the task is fun. If it isn't, it isn't going to happen. If you want something from an OSS project, put your money where your demands are.

You want more documentation for doing X, pay for it. You want feature Y, likewise. And by paying for it, I mean anything from offering money to submitting a patch to adding to the documentation.

It is a very simple concept. And the best one I can think of.

time to read 2 min | 204 words

I was a blast, I had a lot of fun, some incredibly interesting conversations, and got to meet a lot of the members of the community that I have only knew by email alias before.

We had some really good discussions today, and I got to clarify some thoughts that have been luring in the back of my mind for a while now. After the ALT.Net conf officially ended, we started hanging around, swapping stories. Somehow it got to 8 PM, I am not sure how. Roy took a bunch of us that remained to dinner at a nice place. I haven't had a drop of alcohol today (unlike the entire last week), but I am feeling more drunk than on any other day.

I would like to take this opportunity to thank TypeMock for sponsoring the dinner. It was wonderful, although I have trouble walking and / or thinking.

Doing MVP Summit and ALT.Net, back to back, is a real tiring experience.

That said, got a lot of stuff to think of, and will probably generate quite a few blog posts.

Thanks for all those who attended, for creating such a rich discussion.

Special thanks to the sponsors, Version One, ThoughtWorks, Microsoft P&P, DigiPen, DevTeach, InfoQ and CodeBetter!

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. API Design (10):
    29 Jan 2026 - Don't try to guess
  2. Recording (20):
    05 Dec 2025 - Build AI that understands your business
  3. Webinar (8):
    16 Sep 2025 - Building AI Agents in RavenDB
  4. RavenDB 7.1 (7):
    11 Jul 2025 - The Gen AI release
  5. Production postmorterm (2):
    11 Jun 2025 - The rookie server's untimely promotion
View all series

Syndication

Main feed ... ...
Comments feed   ... ...