Zend Framework becomes Laminas project

Today it was announced that Zend Framework is being rebranded as Laminas project. (drawn from the meaning “a thin layer”) Along with the rebrand comes some other important changes as well. Yes, this includes Expressive and Apigility, so continue reading.

Some History

Zend Framework is one of the largest and oldest PHP frameworks and has become a staple for enterprise development around the world. As of April 2019, it has over 400 million lifetime downloads of all packages associated with the project, which has seen a 4-fold increase in just the last 2 years alone. Despite this amazing track record, up to now the project has been supported and guided single-handedly by Zend Technologies, and later Rogue Wave Software.

Awesome Changes

Therefore, to continue this growth and receive the best support possible, the Zend Framework team is announcing that all projects under that umbrella will rebrand to a newly formed “Laminas” project“, which aims to continue their mission as an open source project hosted by the Linux Foundation. The transition will enable more companies to provide support for the projects they’ve come to depend on and help it continue to grow. As part of this transition, it is important for them to differentiate the open source project from the Zend commercial brand. Therefore, the new name “Laminas” project was created.

As part of this move, the Expressive microframework, Apigility api framework, as well as the MVC framework will all be part of the Laminas project.

I will try to add more details as they become available to us all, and will likely also do a Twitch stream and YouTube video with Beachcasts and that video can be viewed HERE.

Support Laminas Project

For more information, please see the new site dedicated to the Laminas project, and if you would like to become a member and/or support the project at the Linux Foundation (their blog post), please join and become a member.

Impact to current users

The framework team is working on scripts and tools to help users update namespaces and vendor packages with the renaming. See the video below for more info.

Beachcasts Video

I added this, and a little more content about the Zend Framework rebranding to Laminas project under the Linux Foundation. Check it out below.

10 bad things about consulting, and why it might not be for you

In this video I share 10 bad things about being a consultant, and why a consulting job might not be a good fit for you. Adam Culp of Beachcasts shares points from his experience to help you figure out if being a PHP consultant is the right job for you.

Or you can view this video on YouTube at: https://youtu.be/ELE0G3e7h3c

How to get lines of code in PHP with PHPLoc via CLI or using Docker

This video shows how to get the lines of code in a PHP application by using PHPLoc from the command line or using Docker. PHPLoc is a command line application to generate a small but useful report. Adam Culp will show how to use it from a Docker Container using a Docker Image he created. PHPLoc demonstrated on the Concrete5 CMS codebase.

Key Topics:

  • Why find the lines of code
  • PHPLoc is an application to find the lines of code in PHP
  • Different methods to use PHPLoc
  • How to use a Docker image to run PHPLoc
  • Comments as a code smell

Associated Links:
https://en.wikipedia.org/wiki/Code_smell – Code smells explained
https://www.docker.com/get-started – The place for developers to start with Docker
https://hub.docker.com/r/adamculp/php-code-quality – link to the image used to build the Docker container used in this video
https://github.com/sebastianbergmann/phploc – location of the PHPLoc tool
https://www.concrete5.org/ – Concrete5 CMS code I’m using in this video

What is Enterprise Ready?

First, let me clarify, this post is not about Star Trek and the starship we’ve all come to know. 😉 Further, this post is not to attack any one group, and rather is my (perhaps poor) attempt to help others gain some visibility into what large companies (Enterprises) do, or perhaps should, look for in software prior to using it.

The Backstory

I saw some rumblings over the weekend between various communities where members of one were accusing another of not being “Enterprise Ready”. Of course, the other quickly responded that their tools were already being used in that capacity, therefore, they were indeed “Enterprise Ready”. (If it swims like a duck, it must be a duck.)

Following this I saw many more statements from various folks saying, “We are Enterprise, and we use it, and it’s working fine.”, and “What is ‘Enterprise Ready’ in any way?”

I’m sorry folks, but just because a company “can” or “will” use a given tool doesn’t mean they “should”, and it certainly doesn’t mean a given tool is indeed ready for use in companies reporting to shareholders or having requirements to meet certain compliance thresholds.

The Risks

There are no definitive guidelines to clearly state what “Enterprise Ready” really means, and there are certainly no lists of which applications are, or are not, Enterprise Ready.

Sure, there are different regulations for security, legal, and financial compliances. But even these only scratch the surface and do not clearly define what can/should be used. Especially when it comes to the many open source software packages available.

In many ways, it can come down to what a company is comfortable with. How much risk they are open to accept. And in some cases, how much liability they are willing to ignore and/or absorb when things go sideways.

On other fronts, a companies choices are led by the future. Large enterprises try to plan ahead because they know it is hard to change later down the line. Choices made today are often carried for 10 to 20 years, so it is very important to ensure they do not get caught in the trap of using tools lacking support and/or no longer getting security updates.

How It’s Made

I consult, and work directly with, some of the largest companies in the world every day whom I consider “Enterprise” in size. Since there are no pre-made lists of tools that are definitely “Enterprise”, I will share what many of these companies look at when choosing a tool or software, prior to allowing it to be added to their portfolio for the next 10 years.

The Requirements List

So, off we go:

  • Licensing
    If software/code does not include a license, companies and developers can’t use it. Making code public doesn’t automatically make it open for others to use. By default all code is subject to copyright and private.

    Also, in the same vein, adding an open source license doesn’t mean everyone can use it. Each open source license carries certain criteria which can prevent companies from using the code behind them.So, be careful to understand the ramifications of the license applied to a software package.

  • Interoperability
    Enterprise level companies have lots of software/code. I often see 4+ million lines of code in applications, not including 3rd party code and frameworks. This means that libraries must be able to work together in order to be used.

    In PHP, the PHP-Fig has worked hard for many years in an attempt to create conventions that, if followed, allow PHP libraries and frameworks to work together more easily. Therefore, Enterprise level companies tend to use code that follows the many PSR standards set by this body. Meanwhile, tools that do not follow these standards, regardless of how awesome, are rejected by Enterprises.

    Ask yourself, why should a company create internally maintained wrappers to facilitate “vendor lock-in” when another library doesn’t require such things because it is already interoperable.

  • Lock-in
    If packages of code does not work well with other packages of code, and somewhat forces use of tools created by the same entity, this is known as “vendor lock-in”. Thinking back to the days before open source becoming viable for common use, and I can’t help but remember the days of IBM, Microsoft, Oracle, and others. If one of their tools were used it pretty much meant I had to use others, which amounted to more costly licenses.

    Even when software “appears” free, “vendor lock-in” can exist, and leads toward limiting options in the long run.Enterprises have found less “vendor lock-in” existing in their applications means they can make better decisions and pivot faster. Therefore, monolithic frameworks and packages are becoming undesirable in the Enterprise. Decoupled middleware, microservices, and frameworks are the desired flavor of Enterprise Ready.

    I often speak with companies that say things like, “We want to switch to another framework, and we’ve chosen X.” But yet they can’t substantiate “why”. They use terms like “open” and “popular”, which leads me to helping them create a solid list of pain points leading them to their decision. Usually we find the framework they were choosing will yield the same pain points they desired to leave behind. The number one pain-point is typically “lock-in”.

  • Contributors
    Another very important consideration among Enterprises “in the know” is the number of active contributors to a given software package.

    More contributors means more eyeballs on the code, and often this means less bugs and security issues in a given package. And for Enterprises it can also means bugs get fixed faster, or new features get added more quickly.

  • Bus Factor
    The term “bus factor” is a rather cold term that means if the leaders are hit by a bus, how would that affect something.  If a popular package has a single “head”, and that person were to disappear for some reason, would the package continue without that persons’ vision, drive, and direction.

    I know of many popular PHP packages that have plans in place to facilitate such a tragic event. The more popular a package gets, the more important this is.Of course having such a plan doesn’t always mean the “bus factor” has been avoided. Often the leader is the glue that keeps it all together, and disruption can lead to the death of very strong communities. However, it is important to ensure these plans exist for true Enterprise adoption.

  • Documentation
    No matter how great a package is, or how widely it is adopted, documentation is important to ensure developers can use the tools provided. Some have said that a good developer can read the code and figure out how to use a framework, but that is not what leads to widespread usage. In order to gain true market share it is vital to have great documentation making it easier for anybody to use something.

    A truly strong community helps in this area, and is self fulfilling, as good documentation leads to more usages, and more usage leads to stronger community, who aid in the creation of better documentation.Companies are more likely to use a package if documentation helps their developers create faster.

  • Support
    Despite how good documentation is, occasionally we all get stuck and need a helping hand. Eventually, for a great package to be leveraged by Enterprise it is required that an Enterprise can somehow reach out for support.In the early days of a library this could simply be blog posts from “fanboys”, but for widespread use in Enterprises it may mean more interactive things like phone or email support, consulting, and a “throat to choke” if things go wrong.

    Good support is multi-pronged: support boards, email, consulting, “fanboy” network, outside agencies available, and other forms of community forums.

  • Compliance
    If a package is performing activities with database, filesystem, personal information or content, encryption, and authorization, there may be regulations in place that Enterprise level companies must be in compliance with.

    It is important to Enterprises that code they will use also be compliant, or at a minimum make it easy for the company to remain compliant while still leveraging the package.

  • Longevity
    We all like the new and shiny. However, for Enterprise this can be a negative. They require things to be a bit more tested, and “aged” in some cases. If a library has been around for awhile it can mean a more mature API, less bugs, more secure, and better documentation and examples.

    At the same time, if a package has been on the same version for too long it can also indicate stale and/or dead libraries that will someday no longer be supported.

  • Upgradeable
    How easy is it to upgrade the software from one version to the next, or how easy is it to upgrade from another library, are considerations prior to using a software package.

    Many leading packages go to great pains to prevent breakage between versions, and provide documentation to allow users a step-by-step process for migration. I’ve even seen some create tools that handle the necessary pieces.A company must consider the past track record of a package prior to usage.

  • Roadmap

Enterprise applications tend to stick around a very long time. It is easy to find applications that have been around for 10 years or longer in some companies. Therefore, one thing companies look for is an accurate and active roadmap.

A roadmap can indicate if there are good ideas being developed, and if there are major changes coming in the future that a company may need to be ready for. It can also indicate when a package has lost it’s way and is no longer paying attention to it’s users, and an exit may be a good idea.

In any way, a good roadmap is an easy way to keep Enterprises informed.


I hope you found this post informational. Many developers struggle to understand what defines “Enterprise Ready”, or even why it is a thing to be considered. While there is no definitive list, I have attempted to share what the many Enterprise level companies I’ve consulted with look for.

If I think of more points, or if others share something I feel important enough, I will return here and update this.

Stop the pain, upgrade to PHP 7

When I was young I played football at my local middle school…very terribly. I didn’t enjoy running with the heavy pads in the heat, and I definitely didn’t enjoy running into and hitting the other kids, most of which were larger than me. But in high school that all changed. Why? Because in middle school football was painful. Meanwhile in high school, well, it was still painful but there was something more pleasurable to offset the pain. It was the praises from the coach and the sounds of people cheering my name that truly made the difference.

See, in middle school, the coach seemed to focus more on the larger kids who could bully others, or the popular kids whose parents were the cornerstone of our small community. However, in 9th grade, it changed a bit because the coach was great at distributing his attention to the entire team. He would tell me “good job”, or “you can do better”, and he even let me play a game while my skills were catching up. These are things I didn’t have before, and it made a huge difference. I came to love playing and worked harder than I ever had to stay first string all season long rather than being satisfied with sitting on the sidelines watching others play.

So, now you may be asking, “What does this have to do with upgrading to PHP version 7?” The answer, because many are letting the pain of moving to PHP 7 prevent them from experiencing the pleasure and rewards.

PHP version 7.0 was released almost 2 years ago. (1 year 10 months to be exact.) And many are still running PHP version 5.something. As a matter of fact, PHP version 7.0 is already going to run out of active community support in only 1 month and will only receive security fixes for another year after that.

You can see the supported versions of PHP at http://php.net/supported-versions.php

The Pains

I get it. Upgrading to a new major version is painful. There are backward compatibility issues that caused it to be a new major version, to begin with, and now we need to jump through some hoops without any good reason. I mean, the app already works, right?

Add to this that there may be compatibility issues that have nothing to do specifically with PHP, but rather the individual libraries and packages we used in the past have not updated yet. Dependency hell is only a step away.

Also, how can we possibly endure the pain of explaining why we should upgrade to PHP version 7+ to management!?!

So we should just give up. Perhaps remaining on PHP 5.4, 5.5, or 5.6 is not so bad after all.

NO WAY! Read on!

Acclimation

Those pains aside, there are more that we’ve become acclimated to over time. We avoid upgrading because we’ve become used to the pain faced on a daily basis with what we currently have. It has become our comfort level. Meaning, we avoid the pleasures of advancing because we settle for what we already know.

Pleasure

In case you haven’t heard, PHP 7 brings a whole new level of FAST. Some companies have even recorded speeds of some apps to double. You read that right, “Double the speed in some apps.” That means customers get served web pages in half the time. Internal employees are able to navigate intranets, accounting software, and other internal apps in half the time. Imagine the productivity gains and reductions in salary required to have employees sitting at a screen waiting for the next page to come up. Imagine the customers who don’t click away from our products because it now loads faster!

In addition, many companies also noticed their resources (servers) running PHP apps with PHP 7 have dropped drastically. (about half) Meaning they can serve the same PHP applications on half the number of servers they used previously. If a company was using 100 servers to do business, they are now able to do the same thing with only 50 servers! That is a saving of 50 fewer servers needing to be hosted. Imagine the carbon footprint impact of that!

Note: Your mileage may vary, but many have shared real-time stats on this.

Some supporting posts and stats:

There are other pleasures of upgrading to PHP version 7.0. Among them are new features in the PHP language, such as scalar type declarations, return type declarationsnull coalescing operator, spaceship operator, constant array using define(), anonymous classesUnicode codepoint escape syntaxClosure::call()Filtered unserialize(), IntlChar, Expectations, Group use Declarations, Generator Return Expressions, Generator Delegation, Integer division with intdiv(), Session options, preg_replace_callback_array(), and CSPRNG functions

The upgrade to PHP version 7.1 brings pleasures in the form of even more performance improvements, as well as, Nullable types, Void functions, Symmetric Array Destructuring, Class Constant Visibility, iterable pseudo type, multi-catch exception handling, support for keys in list(), support for negative string offsets, convert callables to closures, asynchronous signal handling, and HTTP/2 server push support in ext/curl

And PHP version 7.2 also looks to carry many more great things, as PHP 7.3 is gaining form.

In Closing

Yes, there may be a little pain in upgrading to PHP 7, but overall the good parts far outweigh the pain. You’ll be glad you did it.

What are you waiting for? Get out there and feel good by upgrading your apps and servers to PHP 7 today!

Not to make this a sales pitch, but if you need any help upgrading, let me know. My team at Rogue Wave are here to help.

There is a great recorded webinar sharing more thoughts on migrating to PHP 7.

Happy PHP’ing!