What is it that you can expect in future releases? Well, that is why we have a road map, but to be fair, it had not been updated in a while. A few weeks ago, the time came for reviewing this page. Considering that we are planning a major release in the next few months, it was a good time to get the road-map updated.
Before jumping into the future, let me review two important improvements that have been released recently.
Dynamic rules generation
We use rules for implementing a variety of behaviour: pricing, plans and mediation among others (this will change in jBilling 3, more about that later). It is then often necessary to be able to create new rules by making an API call, rather than writing the rule by hand and deploying it.
Let’s say that you have a plan that has a few tiers of pricing, from 1 to 100 the price is 1, from 101 to 200 the prices is 2 and so on. Well, this would be easy to put in rules. But then let’s say that you want another plan that follows this same logic, it just acts on a different product, with different prices and on tiers that follow other quantities.
The easiest way to implement this new plan, is to just copy an paste the rules of the old plan, change a few number (the item id, the tier boundaries) and that would do. But this is work, and the kind of work that requires a technical person. Maintaining this is also more and more problematic as more plans are created.
What you can do now is write the rules for the original plan once, as a template. This template is a simple text file available to jBilling. Then you call a new API method that passes the variables to complete the plan. jBilling will take these data, apply it to the template, generate the resulting rules and get them deployed all in one shot.
Want a new plan like this? It is just one call to the API. You created the plan template once, so the involvement of technical people is limited to writing the template. And because this dynamic rule generation is exposed as an API call, you can have a front end that easily creates plans without knowing that rules are being created (or used).
Precision of decimal numbers
Of all the mistakes I ever made (imagine a gigantic mountain), this is the one that got to be the most public and problematic to fix. Back in the days where jBilling was a hobby (happy days those), I chose to represent decimal values using a fast data type (float), rather than a precise one. Of course, I should have known this, but I did not.
As the years went by, jBilling got to be a popular system and being open source everybody can see the code, and comment on it. This is great, it makes one humble fast, so I was very quickly educated about the perils of Float as a data type that represents money. The issue is that by then it was everywhere in the code. Changing all that to something fully accurate proved to take years.
The conversion was a steady process, slowly but surely we removed Floats from the code. With this latest release, none of them remain, and the database schema is now fully converted as well.
The future
The future is very exciting. The pace of development of jBilling is now incredibly fast. Having work on billing systems for the past 15 years, I haven’t seen anything like this. The combination of open source community development and the technologies we are using (frameworks and tools), makes it really fast pace.
I will focus in two really big improvements that you will see in the next few months with the release of jBilling 3: brand new GUI, and product management. To now more about other improvements, take a look to the road map list.
GUI
A brand new GUI is that: a 100% redevelopment of the user interface of jBilling. Sure it will still be a web based GUI, that is a good thing, but with today’s ‘web 2.0’ technologies a web based GUI can maintain its portability and ease of deployment (just a browser will do), while having great response, auto-complete features, gadgets like date picking and so on. And let’s not forget a great look...
The current GUI has changed little since the first release of jBilling. It is not pretty, but the worse is the usability. It is not good. I did it, but I can’t apologize this time: I’m not good at GUI development. Worse, I’m color blind. But at the time, jBilling was a one-man show so I had to do it or there would not be jBilling.
The new GUI is the result of professional graphic designers and UI specialists. We hire the best, but we also have a bigger team to collaborate. For example, Matt, who does most of the training, got quite involved at providing the feedback that the people learning jBilling gave. We also sent sneak peaks to partners and key customer so they can comment.
Stay tuned, we’ll post some beta screen-shots soon.
Product management
Having the option to extend the behaviour of the billing system with rules that are evaluated by a rules engine brings a lot of flexibility to the system. The problem comes with who needs to deal with the rules. You need a certain degree of technical skills to deal with rules, and this is fine for, say, mediation rules. For other rules that fall into the product management category this is not good.
In jBilling 3, product management will be done directly in the GUI and supported straight from jBilling’s core. No need for rules. You will be able to define pricing models: pricing based on quantity, based on tiers, X amount included, after that priced at a certain amount, etc. The main pricing strategies that we see all the time will be available, with many more added in future releases. The best part is that implementing a new pricing model will be easily done by any developer interested in doing so.
Then, you will be able to create a plan that groups a number of products with specific pricing models that applies to the product only when in that plan. So you can have the same product in various plans and have totally different pricing for it on each plan.
It will be both flexible and very much easy to use for business people. Thanks in part to the new GUI, they will be able to create plans in minutes.
PlanetMySQL Voting: Vote UP / Vote DOWN