OpenRasta has been there for many years, and is the most widely used alternative framework for ReST applications.

OpenWrap has been there for a year and a half, and has some usage for advanced users wanting a nicely-architected package manager that doesn’t take dependencies on lots and lots of other technologies and doesn’t require VS.

And we have sub-projects, such as OpenFileSystem, an IO abstraction library that ought to  make using the file system easier, shipping with an in-memory version that should work the same way as your target operating system.

Now all those projects are at varying stages in their life, and the amount of work I used to give to only OpenRasta has been vastly disolved, which in turns means that some users are starting to get quite annoyed with our dreadful homepage and our lack of binary downloads.

Add to this the competitive pressure on OpenRasta introduced by Nancy and the future openrasta copycat WebAPI from the photocopier machine Microsoft, and you’ll understand that the current trend is not sustainable.

This year I’ve decided to simplify my life and delegate much more of my work to a community that has been so far very supportive but very unwilling to contribute anything back. I also want to go back to enjoying working on OSS software to build great solutions and not focus my energy on simply competing with any tool and framework microsoft invents to duplicate existing OSS solutions. I have a vision and I want to deliver on that, OpenRasta and OpenWrap are two sides of that, and I want to start making them work together the way I want without having to be dragged in competitive races with Microsoft’s marketing dollars.

So we had a planning meeting with some of the companies that use OpenRasta in anger in London and want to step up their contributions (7digital and huddle, we love you guys!), and decided that we were going to change how things are done in the OpenEverything projects.

Project organization

First and foremost, I’m going to contribute much less to the 2.1 branch of OpenRasta, and patches / merges / new builds are going to be handled by the contributors that are given write access to the git repository. This gives away a lot of my power.

I’m going to be focusing on the outstanding modules for OpenRasta that add a whole bunch of functionality that will be rolled-back in 3.0: the caching module (soon to arrive in 0.2 version), the new config API (with compact fluent API and convention-based config) and the dynamic / json out-of-the-box support. There’s also a new openrasta-diagnostics module that I’ve started building and want to get out there. I’ll also contribute some work towards the async support that has been requested by some.

OpenFileSystem 2.0 is going to be under Henrik Feldt supervision, and will be a merge of the amazing work he did on long-path and transactional file system support.

All of our versioning is going to be a strict application of http://semver.org 2.0 (which is now the only standard in OpenWrap), so that will solve any breaking changes being introduced without knowing.

Of course, OSS is not a democracy, so I keep a veto right on certain changes that would impact future versions, or architectural changes that do not fit with the vision I have for all those projects. This is give and take, I give some of the control of more than 4 years worth of my development time, but I will keep the main architect role for the time being.

As for releases, anytime someone with commit access wants to create a new release, the process is very simple: they email on the mailing list, and if there’s no majority opposition, we have a new build. Simples.

Orphaned projects

Sadly, we do have some orphaned projects in all this. Mostly, the container support for each of the IoC containers is not up-to-date for StructureMap (tests are broken) and Unity (I have no understanding of the code, so while I *think* I fixed the latest build, I can’t try it out). At this stage, anyone with a vested interest in those projects should start contributing and come help out, or risk that code not being maintained anymore.

OSS is not just take, it’s give too

That leaves a real question for those companies that have used OpenRasta to make money and provide a killer-architecture and have contributed absolutely nothing back since the beginning.

I’ll let you in on a little secret. I give the code away on everything, so it is a company’s legal right to take and not give back. As a side-effect, it is my complete right to completely ignore those that make money on our hard work and want to keep it all to themselves, and my responsibility to not prioritize the needs of those that contributes over those that are selfish..

OSS is also about giving back, and this year it’s what is being enforced on the OpenEverything projects. Fostering contributions is what we want to get to. No more free-lunch though, that’s for sure.

Conclusion

This new organization should let OpenRasta absorb patches and get on the 2.1 release cycle faster, and then on to 2.2, etc. This will allow me to focus on what I want to build for 3.0, and this will also allow more contributors to own projects more directly than before.

If you have comments or feedback on all those new plans, please let us know on the now unified openeverything-dev mailing list.

Please don’t use it for user questions, we’ve moved all support of all those frameworks to stackoverflow where google can do its job and users can find their answers more quickly.

The mythical book, Mythical man month quoted that no matter the programming language chosen, a professional developer will write in average 10 lines of code (LoC) day.

After a bit more than 6 years of full-time development on the tool NDepend I’d like to elaborate a bit here.

Let’s start with the definition of logical Line of Code. Basically, a logical LoC is a PDB sequence point except sequence points corresponding to opening and closing method brace. So here we have a 8 logical lines of code method for example:

See here the post How do you count your number of Lines Of Code (LOC) ? for more details.

I already hear the bashing; LoC has nothing to do with productivity, Bill Gates said “Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.“.

And indeed, measured on a few days or a few weeks range, LoC has nothing to do with productivity. Some days I write 200 LoC in a row, some days I spend 8 hours fixing a pesky bug by not even adding a LoC. Some day I clean dead code and remove some LoC. Some other days I refactor exiting code without, all in all, adding a single LoC. Some days I create a large and complex UI Form and the editor will generate automatically 300 additional LoC. Some days are dedicated solely to performance enhancement or planning upcoming code architecture…

What is interesting is the average number of LoC obtained from the long term. And if I do the simple math I obtained around 80 LoC per day. Let’s precise that I abide by high code quality standard. Each LoC must be covered by unit-tests + all possible code contracts must be declared (of course, not all LoC can, nor should, be checked by contracts and some classes are nit relevant for unit-testing, especially UI related classes).

So this average score of 80 LoC produced per day doesn’t sacrifice to code quality, and seems to be a sustainable rhythm. And what is really cool with LoC, is that, once calibrated, caring about counting LoC becomes an accurate estimation tool. After coding and measuring dozens of features achieved in this particular context of development, the size of any feature can be estimated accurately in terms of LoC. Hence with a simple math, the time it’ll take to deliver a feature to production can be accurately estimated. To illustrate this fact, here is a decorated treemap view of most NDepend components.

Thanks to this treemap view, I can compare the size in terms of LoC of most components. Coupling this information with the fact that the average coding score if 80 LoC per day, and looking back on cost in times for each component, I have an accurate method to tune my way of coding and estimate future schedules.

Of course not all components are equals. Most of them are the result of a long evolutive coding process. For example, the code model had undergone much more refactoring since the beginning than say, the dependency graph for example that had been delivered out-of-the-box after some weeks of development.

There is something else interesting this picture is telling. I can see that all these years polishing the tool to meet high professional standards in terms of ergonomy and performance, consumed actually the bulk of LoC. For example just having a clean Project Properties management is implemented through (model + UI control) =(3.751+2.686) = 6.437 LoC. While a flagship feature such as the interactive Dependency Graph only consumes 2.897 LoC, not even a half of the Project Properties impelmentation. Of course the interactive Dependency Graph capitalize a lot on all the existing infrastructure developed for other features. But as a matter of fact, it took less effort to develop  the interactive Dependency Graph than to develop a clean Project Properties model and UI.

All this confirms an essential lesson for everyone that wishes to start an ISV. It is lightweight and easy to develop a nice and flashy prototype application that’ll bring enthusiast users. What is really costly is to transform it into something usable, stable, clean, fast with all possible ergonomy candy to make the life of the user easier. And these are all these non-functional requirements that will make the difference between a product used by a few dozens of enthusiast users only, and a product used by the mass.