Ivan Nikitin Ivan Nikitin home facebook linkedin rss

Why Frameworks With Source Code Is A Must

We all depend on 3rd party frameworks and libraries in our apps. If you're in iOS market, you likely use SSToolkit or GPUImage frameworks. If you're a web dev, you're either using excellent Spring, ASP.NET or Ruby on rails. And don't forget Java and .NET runtimes fuelling hundreds of millions lines of code every day.

Software is buggy. If your own app doesn't seem to be, it actually is. Even if you have plenty of unit tests, good code coverage in your project and very little technical debt, frameworks you use may not. Some surveys shows that 60% of dev teams regularly discover critical issues in their products after release.

This chart shows portion of Apache Foundation codebase covered by tests. Red means low or no coverage. Green is good. Larger blocks mean bigger projects.

Most developers even don't care to fix compilation warnings they have. These are some warnings compiler produces when building stable Ruby 2.1.1 on my Mac OS machine.

bignum.c:222:18: warning: unused variable 'maxpow16_exp'
bignum.c:226:23: warning: unused variable 'maxpow16_num'
bignum.c:239:18: warning: unused variable 'maxpow32_exp'
complex.c:79:1: warning: unused function 'f_cmp'
complex.c:109:1: warning: unused function 'f_lt_p'
complex.c:116:1: warning: unused function 'f_mod'
numeric.c:1461:10: warning: 'finite' is deprecated
range.c:35:1: warning: unused function 'SET_EXCL'
rational.c:478:1: warning: unused function 'f_rational_new_bang2'
rational.c:583:1: warning: unused function 'f_rational_new1'

These warnings just mean there are a lot of unused methods, not actual bugs. The problem with these warnings - developers get used to them. They know about them, they see these warnings every day. I really doubt if anybody will notice when a new warning appears. It so hard to do this if you already have more than 20. You learn to ignore by looking at them everyday. One day you can't see any warnings your compiler log.

But why don't they remove these unused variables and functions?

Are you still sure, your libraries comes from the rest 40% who rarely see critical issues?

What To Do If You've Found A Bug

Report it. You're lucky if you can just describe the error and that's enough to understand and reproduce the problem. There are some obvious bugs, you can describe in a single line. For example, this issue in Android OS was obvious when developers looked at the function code: "memset allways set '0' instead of value passed by the caller".

Unfortunately, not all issues are that obvious. Quite often, you can't immediately understand what's the cause of the problem. You start debugging just before the error appears to figure out what's going wrong. Now source code for 3rd party libraries can help you. You're able to go through method calls in the library itself. Sometimes you use the library incorrectly and you can understand this by watching how library methods are called and behave. You can notice the thing that goes wrong.

If the bug isn't in your source code, you can understand how the library's code works and hopefully find a workaround. A change in your code that immediately solves the problem.

You should also make a simple project that reproduces the problem and send it to the library authors.

Then intriguing things happen.

Getting A Fix For Your Issue

Most small vendors of commercial (not free) libraries fix issues very quickly.

Juce is a cross-platform toolkit developed by a single person Julian Storer. While it's an open-source framework, he offers a commercial license. I can't thank him more for looking into issues that quickly.

Some bigger vendors have low-bug policy. Guys at DevExpress aim to have no more than 500 active critical bugs. I've been told by their employees they have a very strong focus on fixing issues. They employ "zero-bug" policy in their dev teams. The first thing you should do when you come to work in the morning is to fix an issue. You don't start writing new features if older features are broken.

Unfortunately, not every issue gets fixed. For example, MySQL has critical not-yet-solved issues dated 2006. Situation is so crazy that people celebrate bug birthdays to draw attention to the long lasting issues.

Platform vendors are no better. Oracle JDK has 9955 active bugs as of March 22, 2014. .NET Framework has 1161 active issues. Android OS has 16068 open issues. Apple doesn't allow to browse their bug list, but I doubt they are any better.

I reported issues to Oracle, Microsoft, DevExpress, Xamarin, Juce and some other library vendors. Frankly speaking, chances your bug will be fixed quickly are very low.

What To Do If The Bug Doesn't Get Fixed

It's awesome if there is a workaround - a way you can avoid the issue and still accomplish your task. You write your code differently or write a condition that allows you to "jump over" the issue and you're done. That's the most fortunate resolution of the problem.

Unfortunately, I wasn't that lucky all the time. When worked on Visual Watermark I found that JDK crashes trying to render some fonts. It was an access violation somewhere inside native text layout engine. JDK code tried to call methods of a NULL object.

I reported this issue to Oracle about 1.5 years ago. I didn't expect it to be fixed quickly and it turned out that I was right to make a fix myself.

You should be able to rebuild the library you use. Ignore the library otherwise.

If the library source code is available, it solves two problems.

First, source code helps you when debugging the problem. You can step into and out of methods. Inspect variables and understand what's going on inside the library you use.

Second, it allows you to build and use fixed version of the library quickly. You cannot tell your customer "the problem cannot be fixed because of a bad guy". High chance you will lose him and future pay you could get from him.

Having a source code doesn't mean "open source".

Many framework vendors sell their libraries with source code. For example, DevExpress offers their complete subscriptions with full source code. Cheaper packages come without it. I'd recommend to buy top subscriptions since the price difference doesn't compensate absence of the source code. A single problem will cost you more than you save.

However, not everybody wants to disclose their source code. Even at expense of their customers needs. Vendors like LeadTools will charge you for every installation you make, but still leave you with no way to fix the problem yourself. I'd ignore offers like these, if there are other options.

Take control of your apps. Use libraries with source code.

comments powered by Disqus