A few years ago I started developing a framework for multiplatform mobile development called Nibiru Mobile. After some time went by without making any updates, I started to work on it again as part of a project for AAJ Technologies.
This post will not be about technical issues, nor framework functionalities. If you’re interested in such, please refer to Nibiru Mobile GitHub site. There is a nice Wiki and reference PDF there. Instead, I would like to talk about the lessons learned during the development process. So this post will address mostly problems that I encountered, which is a good thing since you can learn a lot from dealing with problems.
Stabilizing the API
When you start a framework, usually you don’t have all the requirements in mind. So your API will probably change during the iterative development process.
To mitigate this problem, we took a conservative approach: we start with lower version numbers (0.1, 0.2, etc.) waiting for setting 1.0 only when we’re sure that API will have no big changes.
This can lead to adoption problems: some customers are using 0.1, some are using 0.2, 0.3, etc. It is important to make this point clear, because the customer will need to make an extra effort when migrating to a new version. And nobody wants angry customers!
I think this is the hardest point. Not only due to issues mentioned in the previous paragraph, but also due to the problems related to spread the framework.
To widespread the framework, we made it Open Source (with Apache 2.0 license, which is business friendly). Also, we made presentations at Google events, created slides, etc.
But that is not enough. Customers tend to be afraid of new frameworks. And this get worst if the framework is not widely used. But to make it widely used, you need to have customers using it! This is a vicious circle that is really hard to break.
Checking the wave
After starting the framework, we found two frameworks that have a similar approach: PlayN and LibGDX. Those frameworks are intended to build games, but the subjacent architecture is very similar. Also, a few months ago, GWT Singular was announced and we realized that it takes an approach that is similar in many aspects.
After seeing a widely adopted framework that uses a similar approach, my first feeling was disappointment. After all, I had a similar idea but I was not able to make it popular. But then, I realized that it is a good thing. It means that you’re probably in the good track.
In contrast, I started another framework even before, called just Nibiru (for web development), which has no comparable equivalents. At the moment of creating Nibiru, OSGi had a good momentum. But then, the interest for such technology declined and we ended up with a framework that contains unnecessary complexity. Nowadays, I’m more willing to generalize Nibiru Mobile for web development rather than to continue developing Nibiru.
Ideas are hard to transmit
Even when you have a clear image about the framework goals, it might not be clear to other people. Sometimes other people don’t see the advantages of the framework. To mitigate this problem you can:
- Write good documentation (reference documents, wiki, etc.)
- Make presentations (separating them into technical and commercial is a good idea)
- Create demo application (publishing them online is a good idea too, since the user can test it with a little effort).
Even with the mentioned problems, developing a framework is fun. Besides that, you can learn a lot in the process and contribute to the community.
On the commercial aspect, developing a framework will improve the company image and can generate direct revenue by enabling selling expertise on such framework.
Of course, the most important thing is to make a framework that solves a customer problem. This would help with attaining the aforementioned goals.