A software development lifecycle (SDLC) was once conceptually very simple. You bought a licence for a particular software version, which usually entitled you to support and some bug fixes, and when the next major version came out, you bought another licence for that one. It was very simple for the software makers as well; once a major version was released, work could ramp up full speed for the next one. Ongoing support for any version was likely to be discontinued one or two version releases later.
Today, such is no longer the case. The Internet has made users accustomed to the idea of free updates to software available via download. Support for any particular version of software has become impossibly long (Windows XP takes the crown for the longest continually-supported software at 14 years). As a result of these and other factors, various different SDLC models have arisen; some of which are traditional, others more suited to agile paradigms, and yet others that work well in the “free software” world. All the above now provides you sufficient background to explain why Joomla! is switching from its current SDLC model to a new one.
Because Joomla is an FOSS project, it is impossible for its support to be as comprehensive as that of Microsoft’s, for instance (at one stage, Microsoft was supporting 4 different OS releases). Hence, it is important that the SDLC chosen matches the needs of the Joomla project. It is equally important that everyone in the ecosystem is aware of the major ramifications of this new release strategy (using the [major].[minor].[patch] version numbering system):
No more specific Long Term Support (LTS) versions
Previously, Joomla’s X.5 (i.e. 1.5, 2.5) releases were classified as LTS releases, which meant that they would be supported longer than any other minor releases (e.g. 3.1, 3.2, 3.4), and will continue to be supported even after newer minor versions have been released. There is no longer any such guarantee; the last point version will be the LTS version. All major releases (v1, v2, v3 etc.) will have 2 years in the active development phase, and a minimum of 2 years in the support phase after that. If a new minor version is released during the support phase, it resets the 2-year support phase clock. Only the latest minor release within each major version will be supported
Faster and more regular minor releases
Adding features to Joomla could be time-consuming, depending on whether you got it in before the feature freeze cut-off. With less time passing between each minor release, this means developers no longer need to be as frantic as before, giving more time to regression test their features before inclusion in a minor release.
Major releases will break compatibility with previous releases
While it isn’t guaranteed to happen all the time, major releases are the only releases where backward compatibility is intentionally discarded. This means that each time you upgrade Joomla (e.g. from version 3.x to version 4.x), be prepared for things to break.
For regular users of Joomla, what does this all mean? Generally speaking, it means that in order to ensure that you have a smooth updating and upgrading experience, you should always update to the latest minor release of your major version, and that you should upgrade Joomla to the next major version every 2 years or so.
The very versatility of computers makes it next to impossible to create programs that are guaranteed to work under all circumstances. Just the Joomla! CMS itself, for instance, requires a software stack that has at least an OS, a Web server, an SQL server and PHP. Each ‘layer’ of the stack has 3-4 different alternatives, and each alternative comes in many different versions, each version being just different enough from the others that there is no guarantee that if Joomla runs on one specific combination of the stack, Joomla will run on all combinations of that particular stack. (Incidentally, successive Joomla versions do throw away the ability to run on older versions of the stack components).
When you add the bewildering number of platforms to code for, interference due to other software, and user ignorance, the costs of providing technical support to help every user soon balloons. In a 2000 report, the Association of Software Professionals stated that the average cost of support was 8% of revenues, and in some cases were as high as 20%, especially for smaller software companies. Of course, larger companies gain from economies of scale. But if even a giant like Microsoft does not provide ongoing phone or email support for its users without a payment contract, then one surely cannot expect Joomla developers to do the same.
So much for support costs for traditional software vendors, who can build them into their pricing models. For vendors of free and open source software (FOSS), which – like Joomla – is usually downloadable at zero-cost, providing the same level of support to everyone can be prohibitive, if not downright impossible. Alas, TANSTAAFL. Certainly, we at Digital Peak have found it so. Because you don’t pay for the software itself, FOSS vendors are essentially paring down your TCO to support costs. This is as true for Red Hat as it is for Joomla developers like us.
Technical support also incurs opportunity costs. The simplest of all free support methods are user forums – but for every hour we spend on the forums answering questions that likely have been answered before, we lose an hour of programming, designing new features, testing or bug fixing – things which our paying subscribers have every right to expect from us. The inexorable laws of economics at work (sigh).
Because of this, we have decided to reprioritise our scarce human resources (all four of us!) towards quality programming and not free technical support. It was not a simple thing to arrive at this choice; but if we were to be true to our paying clients, we had to put their best interests first. Also, better to have good software that doesn’t require much support than mediocre software that does.
We have a case management tool where every subscriber can file bugs, rise questions or or ask for a new feature for our extensions. Every case will have a staff member assigned, which is responsible to solve that case. The status of the case reflects the progress of it. Means the customer does always know in which state of the processing the case is. Additionally, our issues are organized per release in the same case management tool, to have a transparent software development cycle for our customers. All solved cases which are identified bugs or new implemented features for a shipped release are categorized.
Does this mean that unless you pay us, you will get no help? By no means! We are in the process of revamping our online documentation on all of our Joomla extensions, as well as providing instructional videos on YouTube. When we’re done, you will have access to a knowledge base that will take care of maybe 80% of all the issues you probably will face when using our extensions.
You will also get top-notch support from the Stack Exchange forums (yes, we’re here), not to mention the Joomla.org forums (we’re here too). In a sense, we are outsourcing our forum support to these venues, which are far, far more popular and give you access to vastly greater resources than before. These will solve around 99% of the other problems you might encounter outside of our knowledgebase.
Of course, we remain contactable for issues such as bug reports and feature requests. Making our Joomla extensions more usable and more secure is always high on our list of priorities. But what happens if you need more than that? Well, purchase a subscription. Not only will you get personal support, but you will also be supporting the FOSS business model.
If there’s one thing experience has taught us here at Digital Peak, it’s that accepting online payments on a global scale is incredibly complex. For bodies that don’t need international payment support, it’s easy enough – just have a local bank account and give people direct debit details. In theory, you could do the same for overseas orders – but telegraphic transfers take time and, more importantly, can be very expensive for the buyer. Large organisations with physical presences in multiple countries can, of course, simply create bank accounts in all the countries they operate – but that obviously doesn't apply to Digital Peak. And as for cheques or money orders, that’s entirely out of the picture.
By far and away the best option is still to accept credit card payments. But credit card merchant accounts can be expensive and have criteria you don’t qualify for – and if you needed to accept multiple credit cards, you may need multiple merchant accounts. The better solution would be to work with an organisation that could itself process credit cards, and paid you in cash to your current bank account. These organisations are PCI DSS compliant to fulfill the highest security standards to safely handle your transactions.
Which, if you have been our subscriber for a while, you will notice we have been doing all this time through PayPal. Now, PayPal when we first started out using it was great. Its fees were reasonably low, it had a number of features we liked, we got our money in a timely fashion and most importantly, our subscribers didn't necessarily need to have a PayPal account to use it. In this respect, it worked just like a regular online credit card payment gateway or processor. We needed an account, but it was no real hardship. There’s a reason why PayPal has more or less monopolized the online payment market.
Today, though, PayPal is no longer so great. You can see it start to flex its muscles in various ways, mostly in ways that don’t directly affect us – its anti-porn stance, for instance. However, there is one way in which it has changed which does affect us. That is, it seems to now require you to register an account before you can use it. Apparently, not all countries and regions are affected – but that very uncertainty makes it a non-optimal choice.
Enter Stripe, our new alternate payment gateway. It is a platform which handles all the credit card processing for the merchant, but does not currently require setting up an account on the part of the buyers. It has a host of other features that makes it amazingly attractive. It has a well-rounded API which works on just about every platform that is out there. You can now enter your credit card information directly on our web site and it will be transferred over a secure (https) connection to the stripe platform. We do not store your credit card information on our servers at all.
So if you’re one of those people who’s fed up with PayPal and its aggressive posture, then go ahead and pay for your subscription using Stripe. It’s not any harder to use. And if you’re happy with PayPal, then go ahead – we won’t be shutting it down any time soon. At least now, you have a choice.
More so than any other language, English can lay claim to being truly international. More people speak Mandarin, but most of them are ethnic Chinese concentrated in mainland China and Taiwan. The created language Esperanto is supposed to be international, but it is spoken only by a few million, as opposed to more than a billion English speakers. It is an official language in approximately 1/3 of the world’s nations, as well as that of the European Union. It is the only language used by international air traffic control (a regulation by ICAO). And English words form the basis for most of the more common and popular programming languages. We at Digital Peak are not Englishmen, but we speak, read and write in English (albeit not perfectly all the time).
This being the case, it is not surprising that the early Internet and World Wide Web started out as being predominantly English-based as well. As English is also the international language of the sciences and other academic studies, and as the Internet started becoming popular amongst universities, one can see why this is the case. Today, much of the Internet and the Web remains heavily biased towards English. For instance, Digital Peak’s CMS of choice, Joomla!, supports multiple languages, but the official website is solely in English.
However, that is changing, and has been changing over the past decade. An internationalized software package has access to a greater marketplace, and provides its users with more seamless experiences and wider options. Many factors have come together to drive the internationalization and localisation of software in all the various human languages; the seamless support for Unicode amongst the primary OS players and font developers, the rapid improvement of machine translation, and most of all, crowdsourcing. Joomla itself relies heavily on crowdsourcing for its non-English language support.
Traditionally, translating anything, much less something as complex as software, has been a difficult, expensive and time-consuming process. In addition to the high costs and cultural, sometimes political ramifications that may impact normal translation, software poses its own unique problems as well, since many US-centric third-party developers often assume English language strings and operate on such assumptions. Raymond Chen has highlighted some delightful anecdotes about how the Windows team comes across such issues in his book, The Old New Thing (also the name of his blog).
Today, though, through the power of crowdsourcing, translation of software into different languages no longer has to be expensive or time-consuming (although it may still be a bit challenging). We at Digital Peak use a cloud solution called Transifex. Free for open source projects (they also have paid plans for seriously large projects), Transifex offers an impressive array of features and facilities in order to ensure that translations of all the language strings in our projects are timely, and as we update our Joomla extensions, we can have all the documentation associated with them translated in near real-time.
You, too, can be a part of the Digital Peak translation team on Transifex! Just sign up and apply to be a contributor. We can be found here on Transifex, so come on by and help out. You’ll have the satisfaction of knowing that you helped to make our great extensions even more awesome. The full documentation how to help translate can be found here. We always update the translation files before we ship a new release. Means, you contribution will be shipped very quickly.
I'm sitting in my living room and think about how should I write an article that the loved GCalendar extensions has evolved and will be now DPCalendar Free? Should I write what has changed or why did we do that or where do we want go? I guess I start with some background information about GCalendar and DPCalendar.
I published GCalendar in the JED in 2007, over seven years ago, as a free (in beer and in use) extension. It was the only full featured Google calendar extension for Joomla at that time and continues to be the best Google calendar extension. The first version of GCalendar was created for Joomla v1.0.x series. Over the years many people have contributed to GCalendar. And the forum has grown with almost 25'000 posts. GCalendar has been downloaded over 2 million times at g4j.digital-peak.com.
The demand of the community increased and there were requests for many features that Google's calendar could not support. This meant we should keep the same slick interface but we needed to add the events to the Joomla database, instead of Google's.
We decided to make a commercial calendar version to deliver a professional Joomla calendar and event manager extension. DPCalendar was born! DPCalendar has grown very fast and supports now CalDAV access to its calendars, payment gateways to attend events and tons of external calendar integration plugins like CalDAV/iCloud/ownCloud, Google calendar, Facebook pages, MS Exchange or iCal events (Yahoo, Outlook.com, and many other calendars). To name just a few features.
During this time, GCalendar was at a very stable state and not many changes were needed. We published the GCalendar Action Pack to edit the Google events directly from within Joomla. Minor tweaks and updates have slowed. The options to grow and add new features for GCalendar are very limited due to the Google calendar limitations.
Maintaining three products, GCalendar, Action Pack, and DPCalendar, which do basically the same thing was inefficient. Paul and I were discussing back and forth what should we do. I wanted to reduce the development time to be able to put energy into only one calendar extension. At the same time to provide a healthy free event extension for the masses and a commercial one for professionals with proper support. We decided there must be only one product and it will be DPCalendar. But how should the free version look like?
First we thought that we should slim down DPCalendar and provide it with the Google calendar plugin. But that would be more confusing to the people. They would basically have an empty component and a very powerful Google calendar plugin. A next idea was to make DPCalendar free without the external plugins. But what would be the migration path for the GCalendar users? We didn't want to force them to buy the DPCalendar professional version just to be able to use their existing Google calendars. So we decided at the end to make a slimmed down version of DPCalendar with a GCalendar integration plugin. This means that the free version of DPCalendar has a reduced feature set (no CalDAV support, no attending feature, etc.) and the existing GCalendar users can integrate or import their GCalendars. New DPCalendar Free users will have then events stored into the database and benefit from the much richer feature set than GCalendar had.
The table below shows the different versions and feature sets:
| Feature | Free | Standard |
Professional | Premium |
| Component (The free version does not contain features like CalDAV access, recurring events or the list/map view and some more.) | ||||
| Upcoming Module | ||||
| Counter Module | ||||
| Mini Module | ||||
| Map Module | ||||
| Search Plugin |
||||
| Finder Plugin |
||||
| Ical Plugin | ||||
| Jomsocial Plugin | ||||
| CSV Plugin | ||||
| JEvents Plugin | ||||
| JCalPro Plugin | ||||
| Google Calendar Plugin | ||||
| Facebook Event Plugin | ||||
| CalDAV Plugin | ||||
| MS Exchange Plugin | ||||
| Manual Payment Plugin | ||||
| PayPal Payment Plugin |
The DPCalendar Google plugin uses the newest Google Calendar API v3 with OAuth2 authentication (it is not required anymore to store your google credentials in DPCalendar). This API is much faster because it uses JSON as transport protocol. More features which are available only in this API v3 are event colors. Events can created/updated/deleted directly from your Joomla web site.
The API v3 doesn't rely on Zend anymore which makes the footprint much smaller and the Zend_Loader errors are history.
We migrate all GCalendar Action Pack subscriptions in the next couple of days from g4j.digital-peak.com to joomla.digital.com. The subscription will be turned into a DPCalendar professional subscription with the length the Action Pack had. All subscriptions which are expired or less than two months valid will be activated and end two months after migration that you will have enough time to do the move. We will not leave you out in the rain.
Google is shutting down their API version 1 which is used in GCalendar on 17. November 2014. You can read the announcement here. GCalendar will not work anymore after that, but the DPCalendar - GCalendar plugin will. You will find all information here how to do the migration from GCalendar to DPCalendar (Free).
We always want to provide a free extension for the Joomla community because we get back so much from the community. This means there will be always a FREE DPCalendar version. To the subscribers we offer top notch support, a cutting edge DPCalendar version and tons of plugins like Facebook integration or PayPal payments. I really hope that you are taking the next steps with us and that the new strategy will be a success story for all of us, the team of Digital Peak and the Joomla community.
Sincerely the founder of Digital Peak
Allon Moritz (aka laoneo)
