In a recent article, I called out Drupal, Joomla, and XOOPS on the state of their “user friendliness”. The developers of XOOPS kindly reached out to me and we decided to have a conversation about their Content Management System. The discussion offered quite a bit of insight into what they are doing now and for the future.
The Interview was conducted with:
- Michael Beck, Marketing Team Leader and Project Coordinator
- Eduardo Cortés, author of XOOPS Common Utilities extension
- Richard Griffith, Core Team Leader and XOOPS Chief Architect
(Editor’s note: Beck, Cortés, and Griffith informed TechRepublic they collaborated on their answers and submitted the responses as a team.)
Xoops is a very powerful CMS tool. What, in your minds, is the ideal usage and user?
We’ve seen XOOPS used for so many varied things, it is hard to define a commonality of an ideal usage. Historically, our users were those who liked to tweak and customize their CMS. We were lucky enough to have in XOOPS a very good and solid foundation with the right set of tools, so it was easy to do it for our users. Now we see more developers who would like to build applications on top of XOOPS and offer them to others, and who see XOOPS as a Web Application Platform, that already has built-in security, user permissions management, etc., so they can focus on the application specific “value-add”. As you can see, XOOPS is evolving all the time …
XOOPS has an active user community that is generally quite helpful to users of all backgrounds and experience levels. Wanting to be part of that community would be a good quality for a user, along with wanting a custom dynamic web site. Being slightly adventurous also seems to help.
Considering how much the world has come to depend upon the cloud, do you have any intention of integrating any sort of cloud services into XOOPS?
Yes, absolutely. There are a lot of changes in our next generation system that make living in and working within the cloud easier. We introduce scriptable builds making container deployments easier. We introduce more modularity, letting us drop unneeded components. We introduce additional abstractions for many common system requirements, such as the database, making it easier to swap in the best fit technology for individual use cases.
What is the biggest challenge with developing a CMS tool?
There are probably two key challenges for us:
- The constantly changing technology, and the difficulty to resist the temptations to include every new component in the code. It important to strike a balance between integrating new components and maintaining a functional and updated codebase, all while a group of developers work together. It is essential to keep the focus on those components that the CMS really needs and that will be useful for users.
- A second challenge is maintaining relevance. With several powerhouses in social, sharing and publishing space, things that a few years ago would have been a good fit for a CMS are now a simple account signup away. But, there are lots of niches that are not served by these. Let’s pick Facebook as an example. You can use it to reach a large audience, it is easy to use. Ask a question and your friends can answer. That’s great, right? Great until you want to see that question and its answers again in a year, then good luck finding it. So, if you want to ask about a lost cat, or about that trip you are taking next week, it is very effective. But if you move into any specialized domain, where the question and any answers may stay relevant for months or years, for examples recipies or genealogy research, it becomes useless. Those niches have become a primary target, and servicing them becomes the CMS lifeblood. Of course, you still have to be able to handle the overlap areas, too.
Open source has become the darling of enterprise. What changed to make this happen?
In a word, Linux. When you are a primary component in traditional server, container, IOT device and mobile markets worldwide, it stops being a fringe element, and becomes mainstream. A lot of wonderful Open Source software goes along with this, especially the GNU tools, to make it viable.
One thing people seem to assume is that the enterprise use of Open Source is a recent development. It has been growing internally for years, with each positive experience opening the way for more adoption. Recently, Open Source usage has become visible enough that it is impossible to deny it any longer and retain any image of respectability. It is fashionable now, and the business benefits are enormous.
This pattern has a lot of similarity to the natural cycle of adaptation, as described by Geoffrey Moore in his book “Crossing the Chasm”. Enough enterprise solutions went with Open Source to assure others that the risks and benefits were well defined and manageable. Then, the holdouts and doubters could join the party with minimal risk. Now that it is proven, strategies to maximize the benefit abound.
While in many cases, some of the changes were driven by the desire for “cost saving”, we’re also in the middle of “Innovation” movement happening around the world, with even the city governments looking to become a “Smart City” or “Intelligent community”. More and more companies are looking for the cutting edge new and innovative ideas, and they’ve realized that Open Source is also “Open Innovation” and if they don’t use Open Source, they will fall behind their competitors. Clearly, embracing and effectively using Open Source became a source of competitive advantage.
What major plans do you have for XOOPS in the next few releases?
As you can see on our Roadmap, there are several major additions planned…
- PHP 7.1 compatibility tops the short list.
- Better documentation is a major goal.
- Module improvements including adding object, rather than procedural, based module coding. Additions to XMF, the XOOPS Module Framework introduced in 2.5.8, to further simplify module coding and deployment.
- Database abstraction, allowing for databases other than MySQL. In the first pass, we will be adding SQLite, but eventually targeting all the major enterprise level database products.
- And, as you have pointed out in your article (see “The common problem with Drupal, Joomla, and Xoops“), “Simplicity” and user friendliness is a key to success in the CMS space, so for the last couple of years Eduardo has been working very hard to address it, and for the next-generation of XOOPS, we’ll incorporate his “Common Utilities” extension as our “Presentation Layer”, which will enable best-in-class “user-friendliness” out of the box for all modules developed for XOOPS.
What are the biggest challenges associated with being open source developers?
Time and remuneration can be a significant problem. While open source is exciting work, there are other responsibilities and daily activities that, in some cases, make it difficult to dedicate the time needed to make progress in open source development.
Solid communication is essential to good team collaboration. In XOOPS, as in most Open Source projects, there are developers from all over the world, with various personalities, different cultural backgrounds, using different languages or having different level of English proficiency, and finally, different ages. This can lead to a variety of problems such as disagreements, or even major communication breakdowns and animosities.
Staying focused in a world of constant advancement is another concern. Technology keeps advancing, which is great, but tracking that change becomes a very consuming activity. With so many different exciting developments around the world, it’s always easy to want to try to incorporate the latest shiny new technology or gadget in the project, but as a consequence, slowing down the overall development, or adding too many features that have negative impact on performance.
XOOPS, of course, depends on PHP and supporting products, which have undergone wonderful, but radical changes lately. The changes, like PHP 7 and standards such those advanced by PHP FIG, are making wonderful things possible — interoperability that would never have been practical before are now common, making the sharing of open source libraries more effective than ever.
Combine that change with technologies up and down the stack. Does this Bootstrap work with this version of jQuery? Does this work in Nginx? Can XOOPS run on a Raspberry Pi? (BTW, yes.) Can version X of Y work with version A of B? I have a module written in 2004, can you make it work?
There is so much change, that the learning, tracking and deploying efforts sometime consume more time than new development, but we love the challenges and to make our users happy!
There was a period of two years (between 2014 and 2016) where XOOPS did not release. What happened?
There were not really two years. XOOPS 126.96.36.199 was released in Nov. 2014, and XOOPS 188.8.131.52 was done a year later, in Decemeber 2015, but we waited with the official release till January 1, 2016, to have a good start of the New Year 2016! 🙂 The XOOPS 2.5.8 with its PHP 7 compatibility was released five months later, in May 2016.
But a release cycle is a delicate balance to maintain. For example, the future of XOOPS really depends on our “next generation” release effort. But, any users, or potential users, need a system today, not just out in the future, so we also need to maintain the current series of XOOPS 2.5.x.
There are firm expectations defined for that next generation, and we are now embarking on a series of incremental releases, each preparing us for the additional changes to come. I like to refer to that as “developing for forward compatibility”.
XOOPS as a CMS depends on the availability of modules to make it useful. The XOOPS organization controls some modules, but there are many independent developers, and unfortunately some orphaned or forgotten modules. There are big changes taking place in XOOPS, and it takes time to adapt and standardize the modules.
We are anticipating more frequent releases from here on, each introducing improvements moving us toward our next generation goals.
Explain SimAntz and why it’s important to XOOPS.
SimAntz is a business framework developed on top of XOOPS by developers in Malaysia. We are always very excited to see different uses for XOOPS, and what the developers can do with it, and SimAntz is no exception. It was developed a few years ago, but resurfaced only recently. However, it perfectly illustrates the great advantage that exists in XOOPS and thus embodies our core mission.
The XOOPS “System” module very cleanly separates the module functionality into one place. If the System and the existing modules don’t satisfy your requirements, that “clean separation” makes it easy to define and realize a custom module that meets unique requirements. That simplicity makes XOOPS a very appealing option when facing unique business processes.
For many of us, this is what brought us to XOOPS in the first place. One of our Core developers needed some unique functionality, so he started researching a notable and respected CMS. After a lengthy period of frustration, he looked into XOOPS. In less time than he spent researching before, he had working code and a working site, and now is one of our key Core developers.
SimAntz is very important in that it offers an example of that developer-friendly quality in XOOPS. Its modules will meet the requirements for some, serve as a model for others, and give us insights to improve XOOPS as we study this unique domain and its set of business solutions.
Eventually, we will incorporate some of its components, or our learnings from them, as “common business objects” in our XOOPS Module Framework (XMF) so that they can be easily used by all XOOPS module developers.
Do you plan on integrating more security features, like two-factor authentication in future releases?
Yes, absolutely. XOOPS has always had some extensibility and flexibility in authentication. We have definite plans to improve that, making it easier to manage and customize, as we take advantage of new technologies and improvements. Multi-factor auth is a very high priority.
We also are revamping our application level firewall, a module called “Protector,” with additional detection capabilities, and modernized techniques.
Security has been always a top priority for XOOPS, and therefore it will be always under constant improvement.
Give us your pitch. Why should businesses be using XOOPS?
We’ve mentioned before that using Open Source is for many businesses a source of competitive advantage. Of course, the question is then – why XOOPS?
While there are many common areas that many of the CMS projects today on the market share, there are several unique key advantages that we believe do set XOOPS apart:
- XOOPS has a powerful mix between power and simplicity.
- XOOPS modularity maintains a simple structure, with “clean separation” between modules.
- Developers find that XOOPS module programming has an easier learning curve than alternative solutions.
- XOOPS is committed to internationalization with support sites around the world.
- XMF, our brand new “XOOPS Module Framework”, is our commitment to future compatibility, making code easier to write today and easier to maintain tomorrow.
- XOOPS won’t leave you behind. XOOPS is famous for its migration path.
- XOOPS is committed to open source, secure, scalable and powerful into the future.