I’d like to see Joomla continue to grow and evolve with the rest of the Internet and even pave the road forward for other platforms to make their own natural evolutions forward.
Michael, you have been involved in web-development and volunteer activity over the years. Did you plan to follow Open Source in the beginning, or did this all happen by chance?
It was all by chance truthfully. I started in the Information Technology industry working as a System Administrator in an enterprise environment which meant I was working heavily with Microsoft resources. It wasn’t until I had started working with Joomla in 2010 that I really began to get immersed into the Open Source community.
Please tell us how it’s possible to combine a serious approach of deadlines with Open Source’s optional status and volunteering where team members contribute in their spare time?
It all depends on the software project and the community surrounding it. Just because something is Open Source doesn’t mean that it is solely supported by volunteers. Joomla is truthfully one of the largest examples of a project I can think of where this actually is the case (supported solely by volunteers), which does present a lot of challenges in terms of long term planning. In the case of our release schedule, typically we evaluate the code that has already been presented and goals we want to accomplish in a release and try to gauge a timeline from that, but there is no way to hold anyone accountable if the timeline is missed. As a whole, I think Joomla could improve on measuring timelines and setting reasonable goals so there aren’t so many perceived issues with timelines being missed.
Joomla now has a good infrastructure as for beginners and developers. What is needed to make Joomla more attractive to 3rd party developers in your opinion?
Flexibility and modernization. Developers should be able to integrate tools they are already familiar with into Joomla and use the powerful toolset that Joomla provides in their projects with relative ease. In some ways, Joomla has lived up to its end of the bargain in the form of the Joomla! Framework by abstracting the code that has been powering the CMS for the last decade into standalone packages that are usable beyond just the Joomla CMS. Now developers can integrate code such as Joomla’s Database API or our GitHub API package into their WordPress or Symfony built projects.
In terms of modernization, there are areas of the CMS that we should focus on to make it easier to build “next generation applications”. Some terms that have been tossed around the last few years are RESTful API’s and web services, and these are both crucial to Joomla moving forward. A lot of websites, while still focusing on content presentation, are also building APIs and enabling users to consume the data from their sites, and while it can be done with Joomla, it isn’t very easy. I think enabling platforms to be built supporting these ways of sharing data will help Joomla moving forward.
The CMS is already adopting 3rd party vendor’s code. What parts of the CMS might be switched to them?
Joomla has always used third party code where it’s made sense, and we’re continuing to do so. One of the biggest changes that’s happened in the last few years is adapting a third party presentation library in the form of Bootstrap. Joomla’s been using PHPMailer and the SimplePie XML library for quite some time behind the scenes. With the Framework, we’ve made it easier to pull in tools that might be the right thing for the project you’re working on so you don’t either have to use Joomla’s option (although we would totally prefer it!) or write it yourself. In the CMS, this enables us to more closely focus on our own code base and not need to maintain our own versions of some libraries. This is just my opinion, but I could envision Joomla’s logging and session handling code being replaced with third party code in 4.0, but considering that’s still a long way off, it’s merely an idea at this point.
There will be a Composer integration in Joomla 3.4. Will the CMS gain in popularity among the developers because of this?
Truthfully, that one change won’t make much of an impact. What it does right away is enables our project to more easily manage third party dependencies (instead of copying their code from a source repo and trying to make it fit into our structure, we let Composer do that for us) and opens up an API for developers to integrate other tools into Joomla more easily.
Some 3rd party extensions may increase Joomla security through adding rules in .htaccess file that avoid XSS attacks or block scanning via plugins and so on. Are there any plans to include similar solutions to the Joomla distributive?
The Joomla core distro out of the box has to support a wide variety of configurations and environments and not all of the extension's resources serve that same general purpose. For example, Joomla supports Apache, IIS, and Nginx for web servers, so we cannot introduce code that breaks on one of those environments. This is in part what makes Joomla powerful and flexible too; extension developers can create products that are more fine tuned to specific environments and configurations and do things Joomla may not be able to do out of the box. Of course, we are always monitoring what is happening around us and improving our own security practices and default configurations to give the best product we can.
Joomla is traditionally strong in educational sites and the government sector. Are you planning to implement some new features to J! to let web-masters build an intranet resource or to enhance user’s features in front-end with standard tools?
Aside from the update checks (which can be disabled), Joomla can run just fine today in an intranet environment and disconnected from the rest of the world. Ironically, my first Joomla experience was in an intranet setup. As far as features for the front end, there has been a focus on improving what the user can do, which can be seen in our last few releases. 3.2 introduced a limited system configuration and template configuration view in the front-end and 3.4 will be bringing front-end module editing to users. This is in addition to the existing front-end content editing features that exist with our core components.
When is the Production Leadership Team planning to finish removing all includes of Mootools in the CMS?
This has been a work in progress within our community for some time and continues to be a focus. There isn't a definitive timeframe right now, but as demonstrated throughout the last year, it has been a heavy focus in our releases. We're down to a small number of scripts remaining with MooTools dependencies, and these are the more tricky scripts to convert. Since they also have an exposed API, there has to be backward compatibility within that API per our development strategy. At the soonest, MooTools will be completely dropped with 4.0.
Over the years, lots of people have asked to include basic CCK to core J! features. Has this subject been discussed?
In some ways, you can include basic CCK like features in the CMS today through our plugin system. I don't think it would be a good idea to include a full features CCK in Joomla, it isn't a resource that a majority of site admins would need for their installations. Plus, a true CCK has a high maintenance factor in terms of the code and would add a lot of complexity to our code. In some ways, we began building a CCK like API in Joomla, calling it UCM (Unified Content Model), but I think that top level API should be as far as the Joomla core goes and that extension developers would extend that API to add their features
Some core components (contact, weblinks) are soon to be removed from Joomla. May we expect to see new components, or is the main goal to provide Joomla only with the necessary extensions and allow users to extend website features through 3rd party extensions?
One of the goals is to modularize the CMS to make it easier for administrators to manage their sites and only include the pieces you need. The plan right now isn't to add new extensions to the CMS, but rather break the CMS down into smaller pieces that can be individually updated, or even uninstalled if you aren't using them. The main distro will continue to provide the tools needed to work right out of the box, with one scenario being that you could one day completely remove com_content if you're using an extension like K2.
Since the PLT has limited with resources and cannot control everything, how is it possible to stimulate 3rd party developers to provide better code in their products?
The PLT has nothing to do with how third party extensions are written, all we can do is provide developers with a stable API to build upon and best practices it’s suggested that are followed. The JED team actually has a simple quality control process which checks for some things in an extension’s code, so there are some minimal checks in place for an extension to even be listed in our directory, but the actual code’s structure is up to the extension developer. One of the great things about Joomla is that there is a lot of flexibility in the code, which makes it possible for developers to build extensions in different ways (and introduce resources such as Framework on Framework) and we shouldn’t be limiting that by requiring all developers always follow “the Joomla way” as that truthfully only hurts the developers and our ecosystem.
Does the Bug Tracker work really well, or would you like to see more reaction from the Joomla community? And what about the non-English speaking communities?
It’s hard to tell so far how the new issue tracker has changed things. We had several goals with the tracker, including getting our code and issue systems back into a single location (all of the issues are logged through GitHub and our tracker only expands it), improving interaction with non-English users (the interface is translated in 15 different languages right now, the only caveat is we ask that issue and comment submissions still be in English), and improving the issue tracker’s usefulness. There is a roadmap for future development on the tracker at http://developer.joomla.org/tracker/roadmap.html which outlines how we plan to expand the site. This includes restoring the user activity charts we had published on the Developer Site and consolidating the Ideas Pool into the issue tracker. Lastly, since the Volunteer Portal’s launch during the Joomla! World Conference, there have been a couple of suggestions about integrating the two sites together through an API of some form which would be rather interesting in my opinion to accomplish.
Michael, if I am not wrong you are a passionate traveler. Do you combine traveling with Joomla activity?
I rather enjoy traveling and experiencing different cultures. My last trip was for the Joomla World Conference which was my first time visiting Mexico. In all, I’ve spent time in nearly a dozen countries and plan to visit new ones next year. Traveling with Joomla only enables that; I get to see different parts of the world and meet people I probably wouldn’t meet otherwise be it online or in person.
What are your impressions on Joomla World Conference 2014?
I wrote a blog about it at michaels.website/blog/jselfie-joomler-and-joomlaheart-my-jwc-experience but to sum it up, it wasn’t what I expected it would be going into the event and I personally had a rather positive experience at the event and am glad I attended.
Well, we’re almost done. Michael, thanks a lot for the interesting conversation. The last words to the community are yours.
The last couple of years on the PLT have been really fun while easily the most stressful years I’ve contributed to the project and I’m glad I’ve been able to do well in that role. Stepping out of a role is never easy, but doing so is going to let me catch a much needed breath of relaxation and help me to refocus and be able to contribute my time more effectively going forward. Joomla still has a lot of room for improvement as an always evolving software platform and I’d like to see Joomla continue to grow and evolve with the rest of the Internet and even pave the road forward for other platforms to make their own natural evolutions forward.