July 16, 2018
Mautic Community Contributions
I am truly hopeful that nothing I share in this post steals any thunder from Mautic.org’s announcements later this week (and early next) but I can’t contain my excitement another minute. I’m absolutely amazed at a few recent developments in Mautic and I have to tell you and everyone else what exciting things I’ve seen going on in the Mautic community.
Let me issue a quick disclaimer though first, read this, not every contribution to Mautic involves code. There are literally dozens of ways to be deeply involved in our community without ever touching a single line of code. I can’t stress this enough. Our community has blog authors, social posters, forum moderators, Slack contributors, doc writers, site builders, Mauticamp organizers, other event coordinators and general enthusiasts of all types.
Recognizing Our GitHub Gurus
In this post, however, I am going to focus on those who have been toiling away in the code cave. Those technical titans who spend their time writing code, testing code, labeling code and doing all other things GitHub based.
You’re probably wondering why I’m so excited about our code contributions and the community involvement in GitHub. I’m excited because this release demonstrates our community taking control and ownership of the full Mautic code.
Don’t misunderstand, Mautic has always been and will always be community-led and community-focused. The code, the product, is our product. But, as you might expect as with any project just beginning there is a need for someone to take the lead and maintain the momentum. There needed to be some driving force encouraging the project to become a product. (By the way, that subtle distinction is worthy of a post all on it’s own and you can expect a full write-up on that in the coming days/weeks.)
Because there was this fundamental need, Mautic, Inc volunteered ridiculous amounts of developer time to focus on our project. They donated resources and untold numbers of engineer-hours to help us achieve our product. While this helped our community tremendously this was not the long-term desire of our community (or even Mautic, Inc’s goal) for our future.
I recently shared a post written about Magento which holds incredible value and insight into this philosophy and thinking. And this starts to show why I am so excited. Recently the decision was made to make a strong community push to give this control fully over to the community. Mautic, Inc graciously stepped back from various lead positions in order to make way for community volunteers to assume other positions of leadership. (To be very, very clear Mautic, Inc continues to dedicate resources solely to our community and project. And they will continue to be one of our largest contributors.) But that’s not why I’m excited either.
Why I am excited
I am excited because the community contributions have exploded! We have seen new volunteers step up into leadership roles, contributing more in the code, testing, assuming responsibility for encouraging others to get involved and generally filling the gaps across our community. This community response is incredible.
What this means for Mautic releases
There are a few important notes to focus on as a result of this transition. First, Mautic 2.14 understandably took longer to release than a typical release. As with any transition there is a lot of knowledge and information to be shared and transferred between individuals. This also means a significant amount of process work to ensure things are done in the right and best way. Moving forward these releases should run smoothly and on the typical schedule.
I am personally not disappointed in any way with the 2.14 timeline. You should not be either. This release represents a massive undertaking. In fact, just to put it into perspective, here’s a couple of stats for this release. Please note these stats will change as beta freeze is anticipated to be released tomorrow!
- Mautic 2.14 has 95 merged pull requests (so far) with an additional 52 pull requests still pending.
- Mautic 2.14 has more than 235 code contributors.
- Mautic 2.14 includes 36,000 net additions to the code.
And more! Can you believe there’s even more? But I won’t tell you what the specifics are just yet. You’ll have to wait to hear about those in the official announcement of the release. But quite simply put, this release is massive.
Lastly, I’ll just simply end with an enormous thank you to each of the contributors who have stepped up and filled a spot. You have proven that our community is incredible and even more importantly, you have demonstrated our community is capable. Empowered with the tools and opportunities, you have assumed the roles and responsibilities of leadership with determination and strength. I can’t wait to see our next release (and the next and the next and the next).
July 9, 2018
Commencing Core Monthly Meetings
I am so thrilled to be able to write up the follow-up from the first Mautic monthly core meeting. Before I give you the details about the meeting itself (which will eventually live on Mautic.org’s working group meeting notes) let me share why this meeting is so important. Even if you’re not super interested in the specific meeting notes I believe there’s value in reading through the first part of this post.
What this meeting represents
I have shared in the past about the importance of the Mautic leadership being owned by the community. And recently this has come front-and-center as Mautic.org announced their call for leaders. There’s several reasons why this leadership by the community and for the community is so critically important (and also why this is so difficult for any community to implement and maintain).
I shared an article recently which highlights this struggle very aptly. I’ll let you read the post in its entirety on your own. As a brief summary Magento recognized a significant problem which plagues many open source communities – only a few developers from a single source contributed the majority of the code.
And the response by Magento was both insightful and important:
… Magento created the Community Engineering team with the basic goal that it would listen to and review pull requests. Today a significant majority of pull requests are accepted, but the initial rate of acceptance was lower. Over time, this initiative, which started as more of a “let the community be heard” exercise, evolved to “wow, much of the innovation in Magento is being driven by our community.”
I’ve said it before and I’ll continue to say it: the reason Mautic is able to achieve such clear success comes from the many who have shown the way in the past. In essence, we stand on the shoulders of giants. When we learn from other open source communities we implement tried and true successful strategies. We improve our community. Finally, the result is to give back our stories, learnings, and successes as well.
These other open source experiences taught us as a community the importance of putting more of an emphasis on the beliefs we held. Mautic from its inception has been committed to being community led. Unfortunately, as is typically the case when moving fast, plans and execution can have slightly different outcomes. One release led to another and Mautic fell into a pattern without even knowing it.
This core meeting represents a change to this oversight and a renewed commitment to our core values.
What this meeting contains
Now that we have a good understanding about what this meeting represents we need to get into a bit of the specifics about what this meeting contains. Remember, if you’ve read the various posts about Mautic working groups you’ll recognize that each working group (like #core) will maintain their own meeting schedule and agenda. The topics and purpose of this working group will differ from others but there may be some elements which remain consistent throughout. But because this is the principle example for working groups the meeting contents are shared below:
- Quick recap of topics to be covered
- Review of current release progress
- Outstanding issues or concerns for the release
- Release timeline
- Next release and release leader planning
That’s pretty much all there is to it! Of course items will pop up along the way as they always do, but one of the most important aspects of the meeting is to ensure you don’t stray to far from the agenda. In #core we determined these meetings should not be used to discuss outstanding questions or “new feature requests” unless they are specifically related to the next release.
Important: Every meeting should have a moderator and a specific time limit. The moderator ensures the discussion stays on topic and remains within the time allotted.
Core Meeting Notes
And here we’ll get into the specifics of this meeting and this group. Because this was the first one there’s a certain amount of leniency and extra forgiveness offered for any lack of process or focus however in this case I don’t believe that was necessary. The meeting began on-time and touched on each of the items mentioned above. Specifically here are some details:
- Alan Hartless is the release leader for 2.14.0, he discussed what remained before a beta could be announced. Specifically, the campaign “jump-to” feature was needing some finalization before it could be tested. (Side note: I’ll take responsibility for the delay in 2.14 due to this feature, I requested we delay until this feature could be added).
- The 2.14 release has quite a few outstanding PR’s still awaiting testing. Specifically 58 open pull requests are marked for 2.14 with most requiring a test confirmation still. Currently, the goal is to announce 2.14 beta on July 17 and release 2.14 on July 24.
- The 2.14 Beta period was determined to be held open for only the period of 1 week for this release given the amount of significant testing being done beforehand. But community members are definitely needed to see this beta tested successfully.
- Finally, the 2.14.1 release leader was discussed and announced…but I won’t steal the Mautic.org thunder. You’ll have to watch their blog to hear that news. (I can’t tell you how excited I am about this announcement!)
As you can hopefully see this is an exciting opportunity for the community to come together and make a difference. Every voice is heard and everyone gets to participate. This is our community. This is our code.
This was the first of many #core meetings to come and if you’re interested in joining this particular working group and getting involved in the release strategies from a technical perspective, I’d encourage you to put the next one on your calendar. Otherwise there are many other working groups you can become a part of to get involved. I’ll be sharing some more super exciting news about that in the coming days!
July 2, 2018
Changes to Mautic’s Leadership
Recently the Mautic community shared an incredibly important blog post on their site. I’d recommend you read the full post for yourself but I will give you the summarized version here to make it easier for you. Here’s the lowdown: Mautic community has grown super fast in the past 2 years. When the organization and leadership team were initially formed there wasn’t much of a community (as you would expect). This meant an inordinate amount of work was done by a few people. Again, this isn’t a problem, it’s how everything starts in the beginning.
Mautic began with only a handful of dedicated individuals, most working together during the day and also contributing to Mautic’s open source platform every chance they had. Today, the Mautic community has grown significantly since those early days but the leadership hasn’t necessarily changed at the same pace to reflect the same rapidity of growth.
The most recent blog post shared in the Mautic community was a call for leadership volunteers. There was a call for a series of changes to be made to the teams, organization, and release processes. All of these changes need to be made so the Mautic community might be better represented in the leadership team.
The reason for this change
You may be wondering why this change matters. What makes this governance model so important and why should you care. If it’s not immediately evident the true purpose of the Mautic leadership teams is to distribute power to as many strong, capable, community volunteers as possible. Mautic believes the best decisions can be made for the largest group of people when the leadership represents those diverse people and their interests. When one company is more represented than another company the open source community and it’s direction may be suspected of defining a path forward skewed too heavily towards one particular viewpoint.
The Mautic community rightly recognized this situation and have decided now is the appropriate time to make changes to the leadership to better represent our strong and growing community of volunteers. Personally I find this every exciting. This announcement demonstrates the dedication and commitment of our contributors. We have grown as a community to the point where the vision for our future is shared. I find it exciting because the dreams and ideals I envisioned for Mautic are no longer held alone.
The benefits of open source
And yet even that reason (distributed representation) doesn’t necessarily take into full account the underlying motivation for changing leadership structures and empowering volunteers. The underlying premise which sets the foundation, or belief, that distributed representative control is better begins with open source. Open source has long been proclaimed the winner in the software world. Companies of all size and scale now implement open source software at all layers of their infrastructure (software stack).
More than 90% of all software either contains open source components or is comprised completely of open source.
A large number of these companies would also seek to share their software as open source in an attempt to harness the values and benefits of open source communities. But, these corporations hope to see value without accepting the full definition of open source.
I recently read an amazing article about the Magento community and how they changed their open source approach to increase community contributions. As I read the post I discovered many similarities to Mautic’s own journey (As I expected I would; my friendships within the leadership circle of Magento kept me fairly well-informed as things unfolded over the years.). Here’s the intro snippet to the article, which I believe summarizes the previous paragraph:
The theory of open source is community-driven development…Most open source projects actually attract very little community. As much as a project like Linux or Kubernetes attracts deep developer involvement, most open source projects toil away in obscurity, the labor of love of a single developer. For commercial open source projects that do see significant contributions, like MongoDB or Red Hat’s JBoss, virtually all of those contributions come from developers on a single company’s payroll – Source
This lack of distributed decision-making, and missing community contribution at the leadership level causes many of these smaller open source communities to not achieve the stratospheric success otherwise possible. (Interested in what I mean by this definition of success? I lean heavily on the influences of Jim Collins, shared in books such as Built to Last.)
I believe the only true and right way to build a proper open source community is with a strong, shared vision held passionately by a diverse, equality-driven tribe of leaders. There’s wisdom in a multitude of counselors as the timeless proverb states.
Mautic understands the value of open source
Thankfully, Mautic is not like many other open source projects. We are building a community with this focus and concept in mind. We have set lofty goals and laid a framework to help us achieve them. This improvement to the leadership process is the next step in our journey to success. We believe we are building something to last. We believe as another old proverb states:
If you want to go fast, go alone. If you want to go far, go together.
Mautic has always had the right motivation and goal as a community. Our leadership even in the early days recognized that we needed to go fast to establish ourselves and to demonstrate to the world there was something truly unique, truly special in Mautic. And now we have reached our first of many milestones, we shift to going the distance. Mautic is intent on going far. And we are going far together.
This new leadership and organizational structure proves this point perfectly. If you haven’t yet taken the time to read the post, or haven’t considered the role you might consider playing in Mautic’s future I would urge you to take a moment and contemplate the possibilities. Your unique skills, special talent, and incredible gifts when shared in community allow you to be a part of something bigger than yourself. Find that sense of satisfaction and personal fulfillment by seizing the opportunity to become an influential part of something changing our world today.
June 25, 2018
Making Marketing Automation Productive
I can’t help but look forward constantly to the future of MarTech and what the world will look like. At times I have an incredibly clear vision of what needs to happen and what our ever-expanding abilities with technology will allow us to do. At times I am faulted for ignoring the past and not living in the present quite enough. With abashed hesitation I must accept the slight truth in the statement. I have a deep desire to see Mautic lead the way into the exciting new opportunities which lay just beyond the MarTech landscape today. I believe our open source community and product is capable of reaching points other software platforms simply cannot attain.
But it would be ignorant of me and reckless if I never stopped to remember the goals, consider the past, or explore the present situation of marketing automation as I prepare for the future. I hope you’ll join me through the following short paragraphs as I take a moment to reflect on these three areas (and then of course dive back into a quick chat about what’s coming next!).
Marketing automation’s goal
In any retrospective subject of thought it’s helpful to start by gaining perspective. This perspective typically comes in the from of reviewing the motivation and goals behind a particular course of action or in the case of a product, the problem it attempts to solve. Marketing automation is a solution to a problem (or rather, it is supposed to be). The problem which marketing automation intends to solve is the overabundance and proliferation of personal relationships maintained across a constantly growing set of social media and digital communication channels.
The goal for marketing automation software was simple. Make the marketer’s life easier by automating the communication and day-to-day relationship nurturing which had quickly become an unwieldy,, impossible mountain of tasks. Marketing automation sought to alleviate this stress without losing the personal touch of a handcrafted email delivered at just the right moment.
There’s a couple key ideas in that last sentence. Marketing automation was meant to automate sending a multitude of messages to a growing number of potential customers. But this wasn’t the only focus, the idea existed that these messages should still be personal and feel unique to each potential customer.
Now, that goal has shifted a bit as the technology and society has changed, but we’ll return to that notion a bit later.
Marketing automation’s past
The first marketing automation tools were weak and unimpressive, but that’s not to say they didn’t solve a part of the problem. And there’s nothing wrong with this approach. As is often the case software evolves over time. Companies intent on ‘scratching their own itch’ built tools to be used internally and then discovered others might also benefit from these same tools. So they began to sell them. They created a product to meet a perceived need. And they did so hoping to realize the goals we shared in the beginning.
Practically speaking this mean we saw marketing automation tools which handled processing a lot of contacts and sending them email messages. The “fancy” tools went a step further and allowed these messages to be customized with mail-merge type of functionality. The final piece of this marketing automation past occurred when these tools allowed those messages to be delayed and sent at dates in the future. Now we’ve got the concept of automation. Of course today we would scoff at this idea of marketing automation but at the time this was revolutionary.
Marketing automation’s present
As time passed the companies built to help the lives of marketers slowly grew the concepts and ideas of marketing automation into a superior vision. Today, marketing automation could be better defined as follows:
Marketing automation automates the sending a multitude of messages across a wide number of unique channels to a growing database of potential customers all while making each message personalized and relevant based on the comprehensive digital online profile of each individual.
Marketing automation has come a long way! It’s exciting to look around and see what marketers are able to do now as a result of the current marketing automation tools. Well, maybe I should set the context on that phrase a bit more precisely. Marketers are able to do some incredible things now. Tools, like Mautic, give the ability to send relevant messages based on an individual’s digital footprint very specifically and effectively. Unfortunately, the vast majority of marketers have not yet taken full advantage of these features.
Practically speaking this means much of marketing automation has not evolved beyond mass email sending. Many still use these marketing automation tools just as they did in the past and have not grown at the same rate as the software. This tends to suggest the marketers need either more training and education, or the tools should adapt to be easier to use and understand. Either way, the marketing automation implementations of today are not living up to the potential of the software tools available.
Marketing automation’s future
This realization of the current usages of marketing automation tend to overshadow and intimidate our ability to look ahead at the future of the product and the technology. Recognizing the hurdles we still have to overcome to use today’s software effectively limits our ability to chase the future from a technology standpoint. We need to double-down on understanding, learning, and improving our use of marketing automation as marketers. Only once we are using today’s technology to its fullest are we free to explore what comes next.
But (you knew there was going to be something else, right?) this does not mean we should limit our thinking about the future. We cannot ignore the future and the advancements in technology occurring all around us. Mautic is devoted to seeing and creating the future of MarTech. We are the future of MarTech. My point is merely that we have an obligation to our community and marketers everywhere to do this in the right way. As I share my thoughts about where marketing automation is going and what we are creating in order to lead the way we must continue to educate and help marketers do marketing automation better.
I am extremely excited to share something later this week which demonstrates this belief in continuing the advancement of marketing automation today. Mautic is continuing to bring people together around the world and improve the lives of marketers everywhere. Stay tuned if you want to learn more!
May 31, 2018
Creating MarTech Glue
If you're a digital marketer then you know the struggle. You know the gaps in your marketing stack. Those ever-widening cracks as the MarTech landscape expands. Mautic is creating the future of marketing automation with this new advancement we are calling MarTech Microservices. Want to learn more about what this means for marketer's everywhere? Read this post.
Yesterday I published a post about Filling In The Marketing Gaps and I hinted at returning to a topic I have grown increasingly excited about. I want to share just a few more thoughts and details along with some graphics which I hope will make things easier to understand. I promise, after this post, if you’re simply begging me to stop I won’t post anything further on the topic for a little while. The challenging thing is I’m seeing what I believe to be an invigorating and innovative spark for moving the future of MarTech. And Mautic is positioned on the forefront of it. As a result of all this pent-up excitement I end up thinking about the topic and by extension writing about it frequently. The topic as I’m sure you’re well aware is one we are calling MarTech Microservices. Mautic is creating the future of marketing automation with this new advancement.
The Next Generation of MarTech
There’s a lot of words in there and I realize I’ve completely obliterated the key 6×6 principle (6 words and 6 lines max on a single slide). Let me pull out a few salient points from this particular slide.
Mautic is positioned to become the leader in the MarTech space, based on an open architecture, a flexible framework, and a sustainable path for future expansion and growth.
As I shared yesterday, the very foundational core of Mautic positions us uniquely to step into this role as a leader, pushing the boundaries of what we know to be marketing automation today. Mautic 3 will give our community the opportunity to demonstrate what this future looks like by creating a headless, serverless marketing automation tool. This means a variety of things and I’ve shared it before (ad nauseam?). The purpose of this post is to take those concepts and make them easier to understand exactly what it will look like.
A Complete Marketing Automation Package
This is the first and greatest point that needs to be made with Mautic 3. Mautic will continue to provide the absolute best, most cutting-edge, full-solution marketing automation solution in the world. Even as we explore the many and exciting ways that Mautic 3 will technically change the MarTech landscape and revolutionize many of the services which marketers are already using; we will continue to offer an incredible all-inclusive Mautic product.
Mautic will grow and become better with each release and Mautic 3 will build on the learning as well as the technology of each previous Mautic release. Rather than losing value with this major release we will be able to build upon our history.
Continued expansions through plugins, a renewed vision for the various “builders” (emails, marketing messages, and landing pages) and countless additional valuable improvements through across the platform – some seemingly inconsequential and some more noticeable. (Does this interest you? I’ll share more specifics if this is a topic you find intriguing – leave a comment if you do!)
A Complete Marketing Automation Platform
Okay, this is where things get exciting. This is where Mautic 3 is completely and totally revolutionary. This is where everything changes. This is where the future begins to become the present and ideas become realities. Can you tell I’m getting excited? Because this is the inflection point. This is the Mautic 3 platform.
The title for this section belies the true differences between the previous section and this one. Package to Platform. An incredibly subtle difference in words, but an incredible impact for marketing and technologists. A package is a bundle of things, a group of objects. In this particular case, the marketing “package” is a bundle of two objects: a frontend user interface and an API driven application layer. The Mautic 3 platform refers to these two individual objects. Keep reading to learn more about what this means.
Two Marketing Automation Tools In One
Here is a more direct look at these two completely unique and standalone parts of the Mautic 3 platform. Each one of these tools is capable of functioning completely independently from the other.
This idea of two tools in one sounds far more complicated than it really is. Remember if you get worried or confused — return to the first point above: Mautic is a complete marketing automation package. There’s no need to feel differently about Mautic 3, and certainly no need to worry.
The power of combining two discrete tools affords the marketer the opportunity to be as demanding as necessary for their unique business environments. Mautic is flexible.
If you’re not sure what this bifurcated approach enables then I’d recommend posting a comment or letting me know! But first, keep reading and see if the next few sections explains things better.
Mautic 3 User Interface
The first of these two tools to explore is the Mautic 3 user interface, or commonly thought of as “the frontend”. The user interface (UI) is the part of the Mautic platform the marketers directly interacts with. This involves all the beautiful drag-and-drop functionality of the campaign builder. The powerful and intuitive navigations. And everything related to what is visually displayed in the browser or app.
Feature Highlight: Did you see what I did there? (I said “app”) We have big plans coming for Mautic 3 in this regards both mobile, desktop, and far far beyond.
As the slide above indicates, this marketing automation tool can be used with any “backend” system (you may understand this part more with the next section). Simply put, if you have your data in a different location, or different database, by adding a simple API layer you can take advantage of the Mautic 3 user interface with your own system.
Mautic 3 API
The second tool available in the Mautic 3 platform is the incredibly powerful API. Again, as with the previous “frontend” tool this API platform builds on the previous success of Mautic 2. Rather than a complete rewrite (I trust this will encourage some of you) Mautic 3’s API will expand upon and continue to extend what was done before.
Feature Highlight: Mautic 3’s API is powerful and robust due to the open source nature of the code. Every aspect of the entire platform is required to be available via this API.
When you have an API that is completely and totally capable serving every aspect of the marketing automation system you are capable of using this tool in a wide range of applications. As highlighted in the image above, Mautic’s API can be used to power a variety of other outputs. Regardless of the interface, Mautic can power the backend data processing.
Just as with the previous section, this API can then be implemented by the discerning marketer into a wide variety of different use cases. (For those with a question – this is meaning of a “headless” system)
Diving Deeper into the Mautic 3 API
It is usually at this point we tend to get into the deep and technically challenging part of the Mautic 3 topic and debate and cause some consternation for people. Let’s rehash how we got to this point very quickly.
First, we have a full marketing automation package in Mautic 3, this package can be used as one tool. Second, this package is actually a marketing automation platform consisting of two distinct tools: a frontend user interface, and a backend API. Each of these tools can be used on it’s own. Now, we have gotten to this concept of microservices. If we look at the API tool we can imagine breaking things down with even greater specificity and consider the concept of discrete functionals components.
In the graphic above I’ve highlighted three possible examples of these microservices. The takeaway is simple and incredibly powerful at the same time.
MarTech Microservices are discrete functional improvements which enhance the marketer’s role across their entire digital marketing stack.
These microservices are the glue which bind together the entire vast and confusing MarTech landscape. They can be used independently of the full marketing automation package (point 1 above).
The Mautic MarTech Glue
This is why I get so excited about Mautic 3. We’ve taken a flexible and open source framework and the concept of being adaptable to every marketer’s unique business workflow and magnified it times a thousand. We have the opportunity to take MarTech into the next phase and to enable marketer’s not only through the use of a new and powerful marketing automation package but to seamlessly bring together their entire marketing suite of tools into a single cohesive system with Mautic MarTech Microservices. And this can be expanded even more as we look into the future a bit further.
Mautic fills the gaps between the various and disparate systems in use by a marketer. Mautic does this with the ultimate in flexibility. By no longer existing as only a monolithic platform Mautic is able to fill in the space, adding value, and connecting marketing tools and more across the organization. — Filling In The Marketing Gaps
If you’d like more information not this particular section I recommend returning to my post from yesterday where I shared more detail.
Flexible, Open Source, Connected
Here’s where we bring it all together. Final thoughts on the topic. I’m going to try to summarize the content above and distill it down to the core fundamental points in as clear a terminology as possible. So here goes.
- Mautic is a marketing automation package which offers a full and complete marketing automation experience for businesses to use as an entire system to handle their omni-channel marketing automation needs.
- The Mautic platform consists of two tools: a beautiful and intuitive marketing automation user interface and a powerful and robust marketing automation API framework. Each of which can be used independently as needed in various marketing environments.
- The Mautic API framework contains discrete marketing automation microservices which can be implemented independently of the rest of the platform to enhance existing marketing tools and services.
These three core principles enable the marketer to experience a truly unified digital marketing experience. But it’s important to recognize how these 3 core principles are made possible. This unique ability to be both monolith and microservice at the same time is only as a result of the underlying foundational architecture and beliefs of the Mautic community and Mautic product. Those foundational truths are:
- Mautic is flexible to be used in a variety of means as required by the unique requirements of each marketer.
- Mautic’s open source code means every aspect is available for review, use, and improvement. There are no black boxes. And full transparency exists across the entire system.
- Mautic is capable of providing marketers with a single, unified, connected system for their digital marketing. Being open source and flexible gives Mautic the unique ability to add meaningful value “in the cracks“ left by other systems.
I hope this has helped to make things a bit more clear and also to showcase what Mautic 3 will involve. More than anything, I hope you are beginning to see the vision for what the future of MarTech looks like. Not only the vision of the future, but a better understanding for why this is so important, relevant, and meaningful. The digital marketing landscape is changing, growing, and expanding. What we believe, what drives us to create Mautic 3, is our uncommon, sui generis ability to be the glue to bring it all together and improve the lives of marketers around the world.
May 30, 2018
Filling In The Marketing Gaps
One of the biggest features and benefits of an open source platform like Mautic is the extreme amount of flexibility and customization that is possible. Open source gives incredible power to each business to create a tool that works for them (rather than the business working to fit the tool). Marketing automation historically never had this level of flexibility before Mautic was created and so in that sense I’m excited to see how quickly the marketing landscape has been improved by Mautic.
The crazy part of this Mautic journey personally is the feeling that this has been both instantaneous and interminably long at the same time in achieving this milestone. In reality we’re probably somewhere in between. Mautic has progressed from an alpha release, beta, a stable 1.0, and then a number of releases to the Mautic 2.x series. Along the way we have educated the world about the powers of open source marketing automation and learned a great deal about how to create a world-class marketing automation platform.
Current Status of the Mautic Platform
Today, I am excited to see the widespread acceptance of open source marketing automation as a natural and significant advancement for the MarTech “Forest” (a concept I’ve written about previously). Open source uniquely allows businesses to create campaigns, workflows, integrations, and processes that match their unique requirements. I’ve had the privilege of hearing story after story from those who have found success in a software tool that fits their needs. It’s extremely rewarding to know Mautic is empowering these individuals to do things the way the want to.
Looking Ahead at Marketing Technology
As I consider the landscape today and look ahead at what the future of MarTech looks like I realize there are still ways we can help marketers do even more. What we have done so far is the first step in my opinion. We cannot stop at this point and rest in our success. We cannot pause our forward momentum and progress and consider ourselves to have achieved our goals. This is the beginning. And we must always be looking at what comes next.
The Next Step in the Mautic Journey
I’ve shared the next step recently when I discussed, announcing Mautic 3, and then I shared both technical advancements (yes, I’ve heard this is a highly technical post), and business benefits, timeframes, and even more suggestions based on what I believe is coming next in the marketing space.
There is one particular aspect though which I inherently feel we should focus in on as we discuss marketing technologies, and what moving forward actually looks like. I believe Mautic changed everything by offering an open source flexible platform. I believe being flexible, integrating, and supporting marketers in whatever tools they choose to use from the “MarTech 5000”. This belief compels me to continue to refine and improve what open source marketing automation means. This is some of the reasoning behind my thoughts on Mautic 3. Let me explain with a graphic. This is a sneak peek from an upcoming blog post but I think it perfectly outlines my point.
I love this graphic because it provides a visual representation for a rather abstract concept. In fact, it also provides a picture for the title of this post as well. Mautic fills the gaps between the various and disparate systems in use by a marketer. Mautic does this with the ultimate in flexibility. By no longer existing as only a monolithic platform Mautic is able to fill in the space, adding value, and connecting marketing tools and more across the organization.
Flexibly Adding Value
I highlighted the key phrase in that last paragraph. Adding value. You see, by focusing on filling the gaps Mautic does far more than just connecting various tools in a blind or “dumb” connection. Rather, Mautic enriches the data, adds value, creates additional knowledge, simplifies processes, and improves the marketer’s intelligence into their audience.
Open source gives Mautic the uniquely powerful position in being able to offer this level of customization and separation. Separation in the sense that you can use some of those services without others. I referred to this in previous posts with a term, microservices, and this leads me to the eventual concept and drive behind some of my philosophies for Mautic 3 and marketing automation microservices.
Important: While Mautic 3 has the ability to provide various functionalities as microservices, there is also a full Mautic 3 marketing automation platform as well. (Not to mention an independent robust API platform and an incredible independent UI as well)
Even as I write that I realize there is so many more things I want to share with you on this topic. But I hope this post at least whets your appetite for learning more about Mautic 3 and the reasons behind why what is being proposed for this release is so important. I’ll be writing much more on this topic as well as sharing a full slide deck that highlights the various relationships in more detail. The image above is only one slide in this forthcoming post and I’m very excited to share it with you. Mautic is once again improving the way marketers work and interact with their tools. Stay with me, things are about to get good.
May 20, 2018
Marketing Automation and CRM
There's often confusion and questions surrounding the necessity for both a marketing automation platform and a customer relationship management (CRM) platform. This post highlights the values of each and why both are important for business growth, continuity and ultimately success.
One of the more recent announcements in Saelos was in regards to the first plugin written for the Saelos platform. As you can probably imagine, this plugin focused on the relationship between Mautic and Saelos (for rather obvious reasons: I’m a bit of a Mautic fan). But this plugin represents so much more than just another CRM to marketing automation integration. This “Mautic mix-in” forces us to ask the question: what’s the difference between marketing automation and customer relationship management? Should you use both these systems? (and what’s the difference) I know I’ve been asked this question quite a few times, so on the off chance that this is something you’re curious about as well….read on.
What is marketing automation
I’m not going to lie, writing this headline and starting this paragraph I almost cringe a little. I feel I’ve read a million articles answering this exact same question. I really don’t want to go down that same path answering the same question so in order to preserve my motivation to keep writing, I’m going to give you a callout with a definition of marketing automation and then share some slightly different thoughts about marketing automation.
Marketing automation refers to software platforms and technologies designed for marketing departments and organizations to more effectively market on multiple channels online (such as email, social media, websites, etc.) and automate repetitive tasks. — Wikipedia
That’s the Wikipedia definition of marketing automation. It’s a bit dry, possibly a little outdated, and even a bit vague. But this is the same general consensus you’ll read over and over. I think there’s a missing element here. I have heard it touched on when I meet with others, or attend conferences (like the awesome SiriusDecisions Summit).
Marketing automation has an incredible task of also being the manager of the brand. Sharing the voice of the company with the world, as broad as everyone and as specific as each individual. Just as we talk about the customer’s voice – the company has a voice as well. Marketing (in most instances) takes the primary role in conveying this voice to the public, to future customers, and to existing customers. (This is your first hint in answering the question)
What is customer relationship management
If the idea of answering the question about what marketing automation does is a difficult one to write about; then I’m sure you understand the even greater reticence I have regarding this paragraph’s title. What is customer relationship management (or as most everyone in the world knows to be a CRM)? Again, I’m taking the time-saving method of giving you a definition you can find yourself with a 2 second search and then I’ll give you a thought or two about my take on something different to consider.
Customer relationship management (CRM) is an approach to manage a company’s interaction with current and potential customers. It uses data analysis about customers’ history with a company to improve business relationships with customers, specifically focusing on customer retention and ultimately driving sales growth. — Wikipedia
Again, thank you Wikipedia, you’ve given a wonderful definition that’s both highly explanatory and equally difficult to easily digest. (Side note: I love Wikipedia and get sucked into the site at least once a week)
So CRM systems have been created to manage the customer (and future customer) and improve relationships with them. This is probably the point where confusion starts to creep in. It appears that the CRM is doing the same thing as the marketing automation tool. “Manage a company’s interaction with current and potential customers” — yep, sure sounds like overlap. But I actually believe there’s a subtle nuance here to be explored and understood better. CRM systems are focused on customer retention and sales growth, aka closing deals and making sales. (Second hint in answering our question)
Why you should use both systems
Okay, we’ve got excellent “book” definitions of both marketing automation and customer relationship management systems and rather than introducing clarity it seems we’ve only made things more convoluted and increased the questions surrounding potential overlap. But I left you hints along the way, lets get into this now and see why you should have both a marketing automation system and a customer relationship management system.
We read how marketing automation is designed for marketing on multiple channels and carrying out automated tasks. We then saw that the CRM is designed for managing relationships and increasing sales growth. When it’s filtered down to those two sentences there seems to be less overlap. This is step one. We have to understand not what each system does, but what their purpose is. And now that we have this knowledge let’s build on it to understand why you should use both systems and possibly more importantly why they should be linked.
The “Voice of the Company”
If you believe in the marketing automation being the voice of the company than you will naturally agree that messages sent by the company should be shared with that voice. The value of a unified company voice is incredibly important and has been the topic of books and blogs the world over. If you don’t have a strong link (continuous bi-directional sync) occurring between marketing and sales you won’t have a unified voice. But, why is this true? Let me explain.
Brand management & single communication source
Marketing automation handles the brand, we discussed this already and determined that this management of the company voice was one of the key functions of a marketing automation platform. Or to put it a different way: Marketing handles the communication for the company. This leads us to the reason why you should consider using both marketing automation and customer relationship management platforms (Big deep breath, this is what you’ve been reading for…):
A CRM manages your interactions and relationships and your marketing automation is responsible for sending the messages.
This means your sales team should be sending messages to their customers, and future customers, through the gateway of your marketing team (Remember, they manage the brand and the company voice). This is where we begin to see the slightest crack starting to form in the world of today’s software systems and where I believe Mautic and Saelos begin to differentiate. (Does that interest you? You should subscribe to my blog and I’ll tell you more about it in a future article)
Source of Truth
The source of truth for each contact record lives in the CRM, because as we learned today the CRM is responsible for managing the relationship; but this doesn’t mean the marketing automation system should have less information. Instead, the marketing automation platform must know everything about the contact, plus be able to correctly determine the best channel, time, and message to be sent to them. That message might be a marketing message, but it might also be a sales message coming from the sales team directly.
Two systems, two purposes, one connection
All of this understanding and enabling between the CRM and the marketing automation requires an integration or mechanism for this data to be shared openly between these two systems…a plugin (or in Mautic term’s, a mix-in). And this two-way sharing of information between marketing and sales is what happens today, but it’s not complete yet. We have not yet seen the complete integration between the two platforms (primarily because both are fighting, incorrectly, to be the source of truth).
Why data control isn’t the answer is a great topic and I’d love to say more, but I have written entirely too much for this post; expect to see a separate post soon!
And so, hopefully as you’ve read through the purpose and focus of these two systems you begin to see the value in both as well as the extreme importance placed on linking the two of them together. The answer to the question should you use both systems is a solid yes; because each system has a unique, distinct and important focus.
What comes next is even more exciting. I’ve hinted at it throughout this post, so if you want to know how Saelos pushes CRM and marketing ahead elegantly and beautifully you’ll need to keep reading.
May 16, 2018
Marketing Automation Microservices
Recently I was on the phone with a good friend of mine, he’s not directly involved in a technology sector and as such it makes our conversations incredibly fun, light-hearted, and many times /not focused/ on the highly technical discussion and debates I normally find myself sucked in to. This particular chat however ended up steering into my work and some of my recent blog articles and he made a comment that caught my attention. He said, “Hey man, at some point can you explain what exactly are you talking about with Mautic 3 and this new version you’re constantly getting excited about?”
I’ve written a good deal lately about Mautic 3, from my initial thoughts on the subject, a business benefits piece, to a pretty technical introspective, and even a timeline for how I think it might unfold (yes, it’s aggressive). Being a good friend he had read all these articles, and this meant he knew what I was talking about and what I was doing, but he didn’t necessarily have a strong understanding of what it meant and what it actually would do. What he was asking was a very good question and exactly what I like to hear.
I get great advice from lots of people, but some of the best advice comes in the form of a question, and comes from those that are not too close to the situation. Those questions are the best for me. They help me to re-focus, or maybe to state it better, they help me to step back and see the forest, not just the trees.
The Marketing Forest
I hope this post will be a less technical and better view of the marketing automation forest as I see it. First, I think this is an extremely important point to not overlook. Maybe you don’t call it a forest, necessarily, maybe you prefer to call it a ‘landscape’.
I need to take a quick moment to tip my hat to the incredible work done by Scott Brinker (@ChiefMartech) and his team creating the marketing landscape each year. If you haven’t taken a moment to appreciate it – do it).
Regardless of what you call the space, it’s overwhelming, and as Scott suggested in a recent blog post the space is only going to continue to grow. There will not be a mass consolidation of marketing tools but instead a proliferation as more and more are introduced. This leads Scott down an interesting line of questioning and thinking. I call it interesting because he begins to touch on the very thing I have been speaking and writing about . I’ll touch more on that in a second, but first, let’s talk about the implications of such an expansive (and constantly expanding) marketing space.
Expansion means competition
What we see occurring in the marketing space is not uncommon nor should it be something to be afraid of. Instead, the increasing number of companies entering this market improves the customer experience. As more and more services are offered the customer will (hopefully) find a better and better solution to their problems. At least that’s the idea. If businesses happen to overlap, competition comes into play and the product will improve. (also there is the side effect of potentially lowered prices as well!) .
I’m always a fan of competition, I believe it has been well proven that such competition results in a better environment and experience for everyone. This also encourages companies to be better and better.
There’s a second outcome I see as a result of this massive and somewhat exponential growth. As Scott suggested, and as I’ve talked about many times previously – with so many options and companies available in this space there becomes a greater problem to be solved, a greater need to be met. This is where Mautic is uniquely and (dare I say it) perfectly poised to meet the need.
I recently read an article published by KPCB recently which shared the number of marketing tools that a single enterprise business uses. It’s mind-blowing. Care to take a guess? If you guessed 10-15, you’re off by a mile. If you thought 25-50 you’re getting closer (and by closer I mean halfway to right). The number of different marketing technology services, platforms, or products that an enterprise uses is nearing 100 unique systems. This is the product of an 8,000 tree “marketing forest”. But while some may see a problem; I see an opportunity – a massive opportunity.
I see an opportunity of epic proportion that only an open source, agile, API-driven marketing automation platform can attain. You see, a proliferation of tools means there needs to be some manner for communication between them, some exchange platform for the data to be shared, and other advanced data transformation to be performed.
What this marketing disconnect needs is a connector. Something that can seamlessly integrate with all those tools, fluidly fill the gaps between them, complement them, and improve the marketer’s experience. But this shouldn’t be another app with a fancy UI. Even more importantly this can’t be another platform seeking to be the “data holder”. The one place where all data must be kept (i.e single source of truth)
Side Note: This is a point worth more consideration. Almost without exception every existing platform seeks to be the source of truth. They believe only by owning the data are they able to “win” the competition to be best. Therefore, everything they do is to protect and extend this perceived trophy.
Big Data Is Not the Answer
This point is a big one. Many businesses today focus on big data (or at least they used to). What do I mean by big data? I’m glad you asked. Big data means collecting as much information on as many people as possible. Once all that data is held the theory is that predictive analysis and data scientists can extrapolate potential results and thus make smarter marketing decisions. But there is a shift in the tide and this commonly held belief is wavering.
Interesting Read: If you’d like to learn more about what causes this change in thinking, I’d suggest reading this article: Mastering the game of Go without human knowledge.
If the collection of more and more data is not the answer, what is? What is the solution that makes marketers more successful and handles the overabundance of different and disparate tools currently existing in the marketing forest? Enter marketing microservices.
I realize there are some that fully understand what a microservice is and what value it offers. For those I apologize if I make it sound too simple or oversimplify the technical nature of the definition. My goal is to summarize in such a way that everyone feels comfortable talking about marketing microservices.
Personally, I’ve always seemed to learn best with examples and clear instructions. The simpler the better. (The popular subreddit: explainlikeimfive is a personal favorite of mine as you might guess.) And so I’ve picked a hypothetical marketing microservice to be used. And as you might imagine this is something Mautic is preparing for part of M3.
A Marketing Microservice Example
Almost every marketer I know and every system of record (you know, the place that wants to be the source of truth we explored earlier) has a common dilemma. In fact, marketing automation platforms in particular struggle with this issue on a daily basis. The problem is recognized but the problem is not easily solved. Curious? For our example, we’re going to assume the issue is contact record de-duping. The ability to recognize and remove (or merge) duplicate contacts in a database.
This is a problem everyone wants to solve but everyone takes a slightly different approach and everyone has found equally varying levels of success. A marketing microservice would allow a marketer to send contacts to a headless, marketing automation microservice provided by Mautic, which would de-dupe the records and return the result. Everyone wins.
The result is a marketer with a cleaned database of contacts, existing platforms don’t have to worry that another tool is “fighting” to be the “source of truth” and Mautic has provided a valuable microservice to fill-in a gap. Once again we have the idea of filling in the gaps. A clear opportunity for a fluid connecting of marketing microservices providing highly relevant, extremely efficient, valuable, results.
Side note: Interesting side effect, when the data storage is irrelevant the marketer is empowered to do things better, without worrying about switching costs, data privacy concerns, and which platform is /the/ platform for their data. This changes everything.
And this is only one very simple example of the power and capabilities of a headless marketing automation platform. Don’t let the slightly unusual terminology throw you off – it’s only a technical way of saying, a platform which fits in with other existing tools seamlessly and painlessly, complementing, strengthening, and simplifying existing marketing stacks and allowing the marketer complete control over where and how their data is stored, manipulated, and displayed. But that’s a lot of words! So I shortened it to headless marketing automation.
I hope this has helped to showcase what a marketing microservice is and how it can completely revolutionize the industry. All of the incredible power of marketing automation where and when its needed. No more data security and storage concerns. An improved experience for marketers. Finally, a solid, robust way for 100 different and disparate systems to begin effectively talking to one another and improving each other. This is the type of thing Mautic 3 is prepared to handle. This is the opportunity Mautic, an open source marketing automation platform, is uniquely able to address.
If you haven’t taken a look at Mautic, I suggest you do so now! Maybe after reading this you have some great ideas for other ways marketing microservices can add value in the overwhelming marketing landscape. Join in the discussions being held, add your voice to the Mautic 3 development process and become a part of something bigger than yourself, something that will truly improve the lives of marketers everywhere, and change the way the landscape is viewed.
May 11, 2018
Mautic 3 Proposed Timeline
The next major topic everyone is very interested in relating to Mautic 3 is the proposed timeline for when things will be worked on…and maybe more importantly when they’ll be available to user. I totally understand this desire and want to do my best to answer this question but I truly hope that everyone understands this is not a black-and-white topic and something that can be easily answered. Why? I’ll answer that quickly and with two words: because developers. I say that in jest but the reality is not too far off from that joke.
In an open source community the release of new versions of Mautic are completely and totally reliant on the time and attention of the volunteers in the community. This is a massive strength for us because we have such a large number of volunteers, but can quickly become an Achilles’ heel when it comes to timeframes. Volunteer work as they are able to. This means while I will propose a series of steps below for the Mautic 3 timeline I will not attach highly specific deadlines or timeframe (at this stage).
Now in the future as we begin to move through this process and as we begin to accomplish certain milestones or goals we will have a better understanding of how things are flowing and can at that time begin to establish some rough timeframes for completion.
With this disclaimer in place let’s take a look at the various steps in a Mautic 3 release timeline and what is involved with each step.
This is where we’ve been living. This is the active ongoing discussion that has occurred in the core channel of our Slack group and if you haven’t been involved in that process, I recommend logging in and sharing your thoughts. This phase is anticipated to have controversy, differences of opinions, and different strategies proposed for how everything comes together.
I’ve written a fair bit lately on this topic as we discuss different options. Starting with a discussion about what Mautic 3 might look like, to the technological advances Mautic 3 might achieve, to the business benefits created by Mautic 3.
The desired outcome from this phase is a shared understanding and an agreed upon vision for what we want to accomplish as a community. And I would merely suggest compromise is important to keep in mind as we all work together for the good of the whole (I’m speaking that admonition to myself as much as anyone else.)
The next phase after the discussion phase is a team formation. This shouldn’t take very long but there will be a time period where we want to evaluate who is involved in this team. Anyone in the community can be involved but there are certain traits which will provide greater value to the team. Things such as a strong ability to see solutions in addition to problems. We want problem finders, but not without being solution finders too.
Side note: Problem finders are critically important to our success but if there are only problem finders are also /critically detrimental/ to our success. We must have problem solvers.
Secondly, having technical abilities and interests are vital to this team as well. I’ll try not to make this sound too obvious, but without developers we can’t create Mautic 3. I’ll be the first to tell you, I’m not writing this one on my own!
Consensus on Course
I know it sounds silly to appear that we’re returning to the discussion phase but that is not the idea behind this step. In this step we are taking the outcomes from the discussion and beginning to outline how we (as a team) tackle those challenges and begin development. We also identify what is possible and not possible to complete in a timely manner.
Did you catch that? This is the point where we begin to discuss overall timing for successful release of Mautic 3.
We discuss where we want to go, what resources we have, and what is a reasonable time frame to get there. This is what I mean by consensus on course. The direction is set previously; here we focus on timing and specifics.
Core Areas And Distribution Of Tasks
Next the team begins to identify those specific items that each developer or couple of developers is interested in focusing on. I think this is a particularly important phase because we will make the most progress and find the greatest success when everyone is working on something they love. If you feel passionately about a particular area you will put everything you can into it, and will be able to take incredible pride in the end result. And you’ll know that the end result is something that has been done well. Because you care about it.
I am driven by this mentality on seeing others doing what they care about because I do what I love every day. I am committed to seeing others in our community free to focus on the things they are passionate about as well. Do what you love or move on to something else. This isn’t a duty, Mautic isn’t a chore, it’s an opportunity. Yes, at times Mautic may be a /challenge/ but that only makes the outcome better.
Key things to be examined at this stage will be specific areas and leaders for each: Every functional and foundational part of Mautic will need to be addressed. Examples: Campaigns, Segments, Contacts, Companies, Email Builder, Landing Page Builder, Messaging and Channels, Plugins, etc… Let me be clear that is not an exhaustive list. Not by any stretch.
Technology Proof of Concept
Once all the areas have been identified and work is clearly defined the next step takes place rather quickly. In my opinion this is a key validation step in the entire process. The idea of a proof of concept is focused on creating a representative example of the final product.
The goal of a proof of concept should be to confirm the path and technologies chosen to be implemented or clearly identify the ways the current approach is wrong and what should be done instead. That last sentence is super important. It’s more than just showing something doesn’t work. In the case where there is a misalignment of expectation and outcome, an alternative approach should be identified. (Remember earlier? It’s not just problem finding, it’s problem solving)
Once as a core team we are able to evaluate whether the proof of concept has given us the necessary results we can move on to the next step. Keep in mind that each major component must meet a minimum level of expected result for the progress to continue.
Go Go Go
This is the exciting phase. This is where everyone is turned loose to start creating Mautic 3 code. We have a direction, we have a plan, we have a solid proof of concept and we are prepared to create the future.
As we create new things it is critically important that we include testing at every step. This something that was not done as effectively as well as it should have been done during Mautic 1 and even Mautic 2. I can only imagine there was a collective groan emitted by everyone when reading this part. Writing the unit tests and functional tests associated with new code is only interesting to a very select few. (I hold massive respect for those who find pleasure and personal fulfillment in creating these test processes and procedures.)
This phase is also where collaboration is important. Without proper collaboration we will find ourselves working in silo’s too much. We can’t work without collaboration and sharing of information. Do not let the importance of this collaboration be lost as we look at the next phase below.
Silo Alpha Testing
Because we will be creating tests as we build new software we should be able to test our code as we go as well. I’m referring to this as silo testing because it can be done within each functional unit without having to be applied to the greater product at the same time. Again, an API driven micro-services marketing automation platform gives us the ability to do this silo’ed testing
During this stage we will also be refining and modifying this code as we go either to make sure it functions optimally or because we have seen additional improvements we can make as we create Mautic 3.
Bringing It All Together
Everyone gets excited at this particular step. Here we are bringing each of the individual pieces together and begin to evaluate what Mautic 3 looks like. This community core team gets the first sneak peek at what Mautic 3 will present to the world. Yes, this will be an exciting day.
As part of the process of bringing all the pieces together we will repeat some of the steps we undertook during the Silo Testing phase above. We will again evaluate and refine the product based on the interactions between the various parts and identify ways in which the whole of Mautic 3 can be improved to be more than just the sum of the parts.
Important: This should not yield any massive surprises to the team because it is understood that communication and collaboration has been occurring frequently through each of the previous stages.
Alpha Release Deployment
This is the first of several celebration stages! Here the core team wraps up and presents to the community the alpha version of the brand new Mautic 3. This is a milestone moment not just for the core team, and not just for the Mautic product, but for the Mautic community and the world of marketing automation at large.
The Alpha release is the first fully packaged version of the final Mautic 3 product. It will not be without issues. Did you read that? If you’re following the process of Mautic 3 development and you’re not part of the community core team creating this product it can be easy to miss everything that has gone into this process. And it can be easy to point to problems. May I encourage you to exercise discernment and caution as you do so. Feedback is of course welcomed and encouraged. But everyone should maintain the proper perspective and understanding of the status of Mautic 3 at this point. This is an Alpha release with known issues to be found. Do not use in production.
So, if you’re skimming through this article looking to find specific dates I’m sure you’re disappointed. But you shouldn’t be. Instead let me encourage you to scroll back up and read through the points with a bit more intentionality. Then you’ll understand why the dates are not listed. It will not be until we have reached Consensus on Course that we will have a better understanding and a first attempt to outline specific dates.
Let me reassure you, when we get to that phase, we will absolutely and unequivocally share some preliminary dates and deadlines. Without a clear goal we will meander without enough of a sense of urgency.
Now, if you’re still reading and want just a ballpark idea of dates, the following is my opinion on dates and relevant release points.
- Discussion: May 15
- Team Formation: June 1
- Consensus on Course: June 7
- Core Focus: June 15
- Proof of Concept: July 15
- Go: September 30
- Silo Testing: October 7
- Alpha Release: October 30
Disclaimer: This is my personal opinion only and is not a finalized roadmap. If anyone attempts to quote these dates as “official” you’ll be immediately and unequivocally corrected!
Please also notice I am not showing beyond the Alpha, as we get this far into the future it becomes more and more difficult to identify deadlines and milestone dates. I have ideas and goals in my own opinion which I think would make for an amazing 2018 but will not share those with you yet. I believe as we move along these steps we will be able to gain more clarity into what is possible and along that path I will feel more comfortable to share specifics on other areas of Mautic 3.
I hope this helps give you greater visibility and understanding into what I believe would give us an incredible future and the path I believe would help us get their. Don’t be disillusioned this will not be easy; but I am confident that the rewards we will reap will be well worth every day spent, and every problem tackled. I hope you’ll agree and you’ll join me as we create the future.
May 10, 2018
The Business Benefits of Mautic 3
Longer posts are always an undertaking. It involves a lot of thought and attention to detail to make sure the information I share is clear and easy to understand. There’s a lot of work that goes in behind the scenes for a finished post to come across as simple. So, usually before undertaking a post like this I like to take a deep breath, a big stretch, and smile. Something about staying positive before wading into the deep end once again.
I should say also, the smile comes from the amazing volunteers in this outstanding community. Together we are building an amazing platform that stands out from the crowd and differentiates us in a number of critical ways.
One of the biggest ways we can demonstrate our expertise lies in our ability to push the envelope and advance new thinking in the landscape of marketing automation. Yes it may be a daunting task, but I would suggest that our community, and our open source approach to marketing automation is the only way this level of growth can be achieved in a stable fashion. We have an opportunity that no one else has. And it’s our duty to push this space forward. It’s our obligation to change the world of marketing and give everyone the tools to market effectively using the latest in technology.
With that quick bit of motivation to get us started, let me dive into the business benefits of Mautic 3. I’ll follow that up with a proposed timeline for this product improvement as a separate post.
Let’s start by exploring the business benefits by making this shift to the next major release of Mautic software. I want to highlight that these six benefits I’ll suggest are not necessarily distinct only to a Mautic 3 release. However, in each case I believe the greatest growth and leap forward would be realized in a major version release.
Stay with me to the end; I’ll discuss in a little more detail tomorrow the idea of migrations and how those would and should be handled with a transition like this.
Speed (Should I say Agility)
At the risk of sounding extremely cheesy I noticed as I typed up these benefits that many of them ended in the same suffix and sounded like they fit together. The marketer in me could not help but then adjust the one outlier (Speed) to also fit this same mnemonic. Thus, for point 1, we have agility, or speed, as an improvement that the end user would experience and thus become our first business benefit. Faster is better (in almost everything – yes, I realize there are exceptions to every rule). Moving to Mautic 3 for our platform will enable us to completely gut parts of the system that have experienced significant slowdowns in the past. Those areas where we see bottlenecks in processing times can be alleviated and the problems with overall system performance can be improved.
Of course we could see improvements in the current branch (Mautic 2), however, due to the discussion that has been held it has become evident that the greatest improvement to speed can be done with a re-write of several areas of the platform. This begs the question – if we must re-write core parts of the platform regardless of the branch in order to improve our speeds, should we not make the necessary improvements to improve speed everywhere and better structure our underlying architecture for the future at the same time? The argument is an easy one to make, in particular when considering our existing infrastructure is reaching end of life for support and we have fallen significantly behind the latest current release (by multiple versions). This must be addressed.
An improvement in our overall speed continues our competitive advantage as we already enable businesses to complete processes in a faster manner than other marketing automation platforms today. This furthers our lead in this area.
The second area where a Mautic rewrite gives us a business benefit lies in the flexibility of the platform. We already built Mautic in an open source way that allows businesses to create a marketing automation workflow that suits their unique business needs but that was always step one in a multi-step plan. The next step in that journey involves giving the business even more flexibility to manipulate and control their data.
Mautic 3 enables businesses to take advantage of existing data stores, and other sources of truth beyond the Mautic database by enabling the separation of frontend from backend code and functionality. Any database that incorporates the necessary API endpoints will be able to take advantage of the Mautic 3 frontend (and vice versa). I spoke specifically to this point in a separate blog post which I would encourage you to read if you’d like to know more about this point.
Mautic was created from the beginning with the concept of mixins – the addition of functionality to the core platform through a Mautic Marketplace which closely resembled a CMS extension directory. This was a fantastic first version and demonstrated that the desire and interest from a community and business perspective clearly existed. With the launch of the new Mautic.org website at the beginning of 2018 we saw a massive uptick in the number of integrations and their downloads.
Businesses wanted this ability to integrate. We wanted to continue in this direction with an overhaul to the existing mixin (plugin) infrastructure and architecture in Mautic 2. But this is still only a step in the journey. Extraction of the existing mixins from core and the unique repositories linked to each mixin allowed for faster development and release of individual integrations. Mautic 3 pushes the software even further in this regards. This is done by doubling down on the API integration layer and the manner in which these mixins talk to the backend (and frontend) of the platform.
I’ll touch on this point in greater detail below as this serves to become a very unique selling point for Mautic and a massive differentiator for our platform in the market. Let’s look at that next as we discuss defensibility.
One of the most challenging obstacles in any company (or community) is understanding and identifying the manner in which the software being created is defensible.
Side note: When I use the term defensible I am referring to our ability as a community to offer something unique that our competitors will never in reality be able to achieve or offer to the same extent as we can.
Understanding what makes a product defensible is a challenge in and of itself and often is very difficult to do in the earliest days of a community. Therefore Mautic 3 is the opportunity where we can begin to apply our learnings in the marketing automation space and begin to clearly define those areas and functionalities where we are unique and defensible.
And this is where the excitement builds for me. This is the culmination of our learning, our open source core, and our ability to push the marketing technology landscape further. Our defensibility is found tucked into many of these business benefits I’ve shared already and will share in the next two points. The underlying mechanism and ability for our open source platform to be split and used interchangeably either from a frontend UI or as a backend API gives us the unique and defensible ability to be the first ever truly open source, API driven, suite of marketing automation micro services.
I know you’re probably very interested in hearing more about this but I’m going to simply say, you’ll have to wait for that specific blog post if you’re interested in digging in. I promise you I’ll publish it soon, because when something is this exciting I have a very hard time keeping quiet for long.
The concept of extensibility as different from integrability is nuanced and tenuous at points. But I would suggest the differentiation is clear enough to allow extensibility to be a separate business benefit. Just as integrability allows the software to work seamlessly with other tools “plugged into it” the idea of extensibility allows for the core functionality of the Mautic platform to be extended to additional areas and implementations.
This underscores the notion that an open source API driven marketing automation micro services platform can do far more than any monolithic platform ever could and allows for the functionality of the platform to extend far beyond the limited reach of existing tools.
Extending the platform requires an API first approach as recommended for Mautic 3. This level of abstraction provides the tools and system interoperability necessary for this business benefit to be properly realized.
The final point I’d suggest as a business benefit for moving to Mautic 3 is a tricky one, particularly because it requires more than simply creating new software. In order for Mautic 3 to be substantially superior to the existing latest release of Mautic and provide additional business value in the sense of a superior stable product implies several fundamental truths. First, Mautic 3 can’t be merely “new code” – it must be tested code. By this I mean while the code may be new, this does not require it to be either untested or unstable.
New Mautic code will not be merged into Mautic 3 until it has the appropriate unit test coverage and functional tests. Otherwise we run the risk of experiencing the same flaws and bugs as Mautic 2. Very fast releases of new features but this surpasses the number of fixes provided to reported bugs.
Therefore, in a release of Mautic 3 we can create a solid, and fully-tested platform capable of being improved upon as needed without fear of the potential to break something unrelated with each new feature release. Overall the stability of the platform is massively improved, the documentation excels, and the usability demonstrates an excellent product. (Read this post I shared recently on the topics of stability, why I think it’s important and what benefits it will provide us.)
May 4, 2018
Mautic Release Strategy 2018
The Mautic community has a history of various release schedules and timings as we’ve sought to find the best strategy that works for our devs and our users. This tends to be one of the biggest ongoing challenges facing software projects everywhere regardless of the size. We don’t want to create a strategy that is too intensive for the users to maintain and stay current. We don’t want to stuff too much into a single release and hurt our testing strategies or sacrifice our QA process. And on the other end of the spectrum no one wants to wait for years for a release.
This constant back and forth struggle will more than likely continue and I don’t anticipate that we will solve it here today. But I want to share what I believe is the best release strategy for Mautic today.
Side note: Mautic follows semantic versioning. If you need a refresher on what this means, read this article. In summary, Mautic releases three types of releases (X, Y, and Z) and our versions are numbered accordingly: X represents a major release (1.0, 2.0 etc…) this release may break backwards compatibility. Y releases are minor point releases (2.1, 2.2, etc..) these releases introduce new features but maintain backwards compatibility. Finally, Z releases (2.1.1, 2.1.2, etc…) are sub point releases which address bugs and fix issues without introducing new features.
Now, rather than going into the historical study of what Mautic has done in the past we’re going to look at a strategy for future releases. I’m basing the following on discussions I have held with many in the community, observations from other successful open source projects, and my personal experience releasing software to large audiences. I
Major Releases (X) are released on a bi-annual to annual strategy. This time frame may fluctuate depending on the volume of work to be undertaken and the code to be modified. Sometimes this process may require extensive testing and significant discussion. Due to these factors major releases are scheduled for either every 6 months or 12 months.
Minor Releases (Y) are released on a monthly basis. There isn’t a set in stone date specific for these releases either, but rather a relative time. Minor releases, when they are released are always released on the last Tuesday of the month. Some months may not have a minor release.
Point Releases (Z) are released bi-weekly. These releases are quick, really quick. These releases only touch bug fixes. There are no new features being added through a point release. Some of these releases may have only a handful of fixes, and others may be packed full of quick fixes. These point releases should be easy to apply and even easier to test.
This should give everyone a clear understanding of what we are doing and when we release new versions. Now since we’re all on the same page let’s get out there and push Mautic forward faster.
Recently I wrote about Mautic 3.0 as the next major release for Mautic. While this is an important step forward for our community and our code there’s something that we have to be very mindful of in the process.
Mautic 3.0 will not happen overnight. While that phrase may seem obvious here’s what it means. Just because we’re talking about and building excitement around the next major release does not mean we are ignoring Mautic 2.x or discontinuing development on the next Minor and Point releases of Mautic. Because the time to development for a major release undertaking (like Mautic 3) will be significant and lengthy we won’t be halting development on the current series during that process. I told you it sounded obvious but it’s worth remembering.
Mautic 2.14 is the next release to be announced and it includes a great number of new features and bug fixes. All of these need to be tested and applied before we can merge and release. And then we will begin working on 2.14.1 (or 2.15 depending on the features we want to include as a community).
Simply put, even while Mautic 3 is exciting and on the horizon we will continue to fix issues, release new features and improve Mautic through the current release 2.x until 3.0 is announced Stable. Are you interested in learning more about how to get involved in Mautic? Testing the next release is an excellent way to start to learn the codebase. Need help setting up a testing environment? Let me know and I can point you in the direction of good resources.
As we move forward in our community-lead releases it becomes more and more important that we test and re-test each new feature and each bug fix to ensure it meets the quality that our community demands.
May 2, 2018
Headless Marketing Automation
Yesterday I released a blog post entitled Looking Ahead at Mautic 3. This blog went into great detail on why I believed a Mautic 3 should be considered next on our product roadmap and then I outlined the problems (as well as some solutions) that we could solve with this next release. One of the features I shared received a few more questions than the others so I think it deserves a little bit of specialized attention.
An API First Headless Application
First of all can we all admit that is a mouthful to say? We can break it down and make it a bit easier to understand and then let’s dig into what it means and why I believe it’s a valuable step for Mautic’s future.
API First implies that every function of Mautic, every call to the database, and every interaction has to be “call driven”. This extracts the front end user-experience from the data layer (or API). This also means that the only way that the user interface (design, page layout, display elements) interacts with the data is through a series of API calls. These calls are the glue that holds the data together. API first means the system has been created in a way that the API is the only way these things happen, and every API return is formatted accordingly.
Headless: This concept is a funny one to discuss when working in software and applications. We’re not getting into the Ichabod Crane story /(though admittedly for some reason a character on a horse holding a pumpkin is inevitably the first thing that comes to my mind)/. In the software universe the concept of headless means something quite different. Here’s a definition:
…the front-end is a stand-alone piece of software, which through API communicates with a back-end. Both parts operate separately from each other, and can even be placed on separate servers, creating a minimum version of a multi-server architecture. The bridge between both parts is the API client. The endpoints of the API are connected to each other….
— Headless software – Wikipedia
Earlier in that same page the first sentence distills it down even further. Headless software is software capable of working on a device without a graphical user interface. (Wikipedia)
By these definitions we see that headless makes sense particularly when discussing things such as API first.
Now, let’s take that thinking and put it into more of a practical application. Why is a headless marketing automation platform useful and desirable. Why should Mautic consider this something worth undertaking in the next major release of our software? Here are my three main points to justify such a task.
In my opinion, the first reason to consider undertaking a task of this size is based on the concept of improving our flexibility as a platform. If our goal is to be “open” (more on that later) then the best way we can do that is by having a platform that is flexible.
Flexibility, to me, means continuing the great work we stated where a business is able to use the software in a way that is best for their business (rather than the situation that 90% of other software operates). We want to give people the ability and the flexibility to be in complete control of their information, their data, and their software. Software flexibility comes in a variety of ways; in Mautic we’ve considered our platform flexible from the very beginning. Custom fields, highly customizable and configurable campaigns, and the ability to create software practices that match a particular business have been part of the product from the start.
The next logical step in this effort to be flexible and to continue to push the limits and lead in this area involves looking deeper at other areas where we can implement more flexibility. Separating the functional layer from the user interface allows just that. A platform where you can consume the data from any interface you desire means you have a marketing automation platform prepared for the future. Your data, made available in any manner you need. API first, headless marketing automation gives you the power of marketing automation in any visual, end product you desire.
The second reason I believe we should focus on a headless approach to marketing automation is for future sustainability. I don’t mean sustainability of Mautic necessarily, but more importantly stability of your data. If you are locked into a single user interface then you’ll find yourself duplicating data, moving between different databases and potentially losing information. You’ll also be tied to a more narrow focus and implementation strategy for your marketing automation because you’ll only be able to use Mautic in the manner envisioned by the Mautic community and its developers.
While this isn’t necessarily a bad thing (we’ve got a pretty good roadmap and vision for where marketing automation should be), I believe the ability for a business to use their data in multiple outlets gives a sense of sustainability to the database and security in knowing the functional aspects of the software is capable of being implemented in a variety of ways. You move from a singular marketing automation-platform-only to a situation where your data (and your marketing functionality) is able to be consumed everywhere by any other service or device.
The final reason I believe that a headless marketing automation platform is beneficial is for the sake of being more open. Mautic is built on open source. We are steeped in the knowledge that our code is readily available to anyone to review, to use, and to improve. This means that every function is understood (or could be), and that every action the software performs is easy to observe. If we continue this line of thinking it stands to reason that in much the same way, the data, and the output from those functions be easy to view, to use, and to improve. By extracting the user interface from the software and making the underlying infrastructure (API) available to be consumed by other sources we make Mautic more open.
No other marketing automation platform gives you this API-first, headless ability. You are essentially “locked in” to their user interface and their experience. (And we don’t even need to start talking about the limited API abilities of marketing automation platforms in general.) Closed marketing automation constricts and restricts your abilities as a marketer. You are forced to understand their interface, and to only view your data within the bounds of what they believe is marketing automation and how they believe you should access your information.
Mautic has always sought to do more, to be more. To provide you access to everything — after all, it belongs to you. Shouldn’t it be able to be used any way you want?
For these reasons I believe it is in best interests and the future success of Mautic to become API-first and truly headless. I hope this shares my thinking in a bit more clarity and if you were unsure before what headless meant you now have a good understanding about the topic.
If you have ideas or other ways in which a headless marketing automation platform can change the landscape and improve marketing I would love to hear them. We’re building this together, our robust and global community of marketers and developers working together create Mautic software and we have the power to envision and create the future. We are changing the landscape and we will continue to do so. It’s an exciting time to be in Mautic.
Special thanks to Don Gilbert for his help with this post.
May 1, 2018
Looking Ahead to Mautic 3
Mautic 1.0 was released out of beta on March 10, 2015. Then Mautic 2.0 was officially released on July 5, 2016. And that’s where we have continued to make improvements. This means we have been improving and iterating within the 2.x release for almost 2 years. This holds both positive and negative connotations. I’ll start with the positive.
This duration of a major release demonstrates the significant improvement to overall platform stability we have seen. It also speaks to the flexibility of the existing platform to be improved and built on top of, without major breaking changes needing to be introduced.
But there are also negatives resulting from a lengthy release cycle like this. We’re building software for the internet, the rate of change of software on the internet is growing exponentially; the technology is changing; and the landscape is shifting — drastically. By remaining in a single major version we limit the ability to take advantage of those technological advances (if we are unable to make those changes without breaking backwards compatibility).
I’ve discussed the versioning for Mautic previously, if you want to review that information but the tl;dr is we use semantic versioning.
For these reasons the time has come to begin exploring the benefits (and potential downsides) to beginning development of a new Mautic 3.0 release.
The first thing we need to identify is the reason why we would want to move forward with a Mautic 3.0 release. We don’t take these large transitions lightly and there must be sufficient difficulties needing to be overcome and/or new features made available by such a move. To that end, the following are the areas (in part) where a 3.0 release may prove beneficial to the Mautic product.
This might possibly be the greatest reason for beginning our discussion around a Mautic 3.0 release. Currently, Mautic requires Symfony 2.8 and only works within the 2.x series. This series of Symfony reaches end of support for bug fixes in November 2018. Meanwhile Symfony current LTS is 3.4.9 and current released version is 4.0.9. This is a very large problem that we need to resolve. A migration from the current Symfony requirement to even the long term support version (3.4.8) requires a large overhaul to our codebase and framework due to some of the deprecated methods. (I can elaborate on this in more detail in a separate post should it be of interest)
We’re learning as a community through this process and some of the design/architect decisions we made in the early days of Mautic have been improved upon and reconciled so as to not lock us in to specific releases of a framework in the future. Regardless, this upgrade plays heavily into the remaining evaluation of an imminent restructuring and release of a Mautic 3.0 version. And as such opens the door for further discussion around framework implementation.
The first item to be considered as an issue that Mautic 3.0 is capable of resolving involves the front-end interface. Mautic’s interface has remained relatively consistent – even through the Mautic 1 and Mautic 2 series transition. But as mentioned, the existing interface has been in place for nearly 3 years now. This clearly points to the success and clean approach that we took when designing the initial Mautic interface. However, at this point it’s time to consider an update, or facelift, to the user interface.
The frontend modifications are more than just surface level though. Currently Mautic 2.x frontend code is deeply integrated throughout the codebase. While we attempted to isolate the code to the /views folder within each bundle we have inevitably had HTML generated and output from other locations as well and this does not lend itself to a clear separation of frontend and backend. Only with a Mautic 3.0 can we overcome this and resolve this intermingling of views.
Mautic’s API is fairly strong, and absolutely open and flexible – you can review it here: https://developer.mautic.org. But as mentioned in the first item above, Mautic is not truly architected as API first. It pains me to say this because our API is so strong, but it’s not complete. There is more we can do. We need to take our API to the next level and make it truly headless.
The modifications necessary to our API to enable this would also require modifications to many of the functions and classes within Mautic. Touching this many areas of the system is risky and poses additional potential problems which is best mitigated during a major version release.
One of the greatest issues we’ve faced with Mautic 1.x and 2.x has been implementing at scale. I’ll address speed in particular in a future point but there are two main contributing factors (primarily) to our latency. Our current database ORM structure is one of those factors. Please understand what I’m suggesting. I don’t believe the ORM is necessarily the problem (though there have been open discussions about the implementation of an ORM as causing speed issues in other situations). More so I am referring to our specific implementation of Doctrine ORM. Many places suggest that ORM should be used for smaller projects with smaller amounts of data or for jumpstarting development as a scaffolding before moving on to a full-fledged data schema.
The three greatest problems with ORM-based development are as follows: First, performance degradation due to metadata, DQL, and entity processing (this adds greater overhead than simply fetching the data). An ORM often makes sacrifices in native performance features of a specific platform because of the way it “forces” a one-size-fits-all approach.
Second, Doctrine does a lot of things behind-the-scenes and without any control by the developer. In these instances, the ORM is treated as a bit of a “black box” where functions go in and data comes out with little to no idea how the actual queries are structured, or how they can be refined. Hours upon hours are quickly lost attempting to debug this data and extrapolate what’s happening “inside the box”.
The third point is closely related to the first: an ORM is quite limiting from a developmental perspective. You are unable to properly optimize your database platform for your specific use case and all queries are in this way forced to be “basic” while at the same time the associations are forced to be overly complex due to the way that the ORM manages the relationships.
The second factor which has greatly impacted our speed relates to our entity hydration. The method by which we make our queries, hydrate the results and return them is often bloated and more than necessary. As a result of this overkill we experience latent page loads. Evaluating our use of entity hydration suggests we are doing far more than we should be and this drastically effects our API call query time.
This affects our API call time due to the way the entities are hydrated. Let me explain, when we fetch and format an API payload we create DQL that Doctrine then translates into SQL and then hydrates those entity objects using \Reflection which we then pass through a serializer that reverse-engineers the entities into arrays and removes the elements we don’t want. This process also involves going back into nested associations and removing those unnecessary items as well. Finally we then package up that outcome, encode it as JSON and return it. (Can you say overworked?)
This same process also goes into our forms and the majority of our UI output. Most of the time we only desire the data, but unfortunately we are returning full objects of data that’s been converted a half-dozen times into different PHP objects and arrays before it ever reaches the UI.
Our integrations is one item that understandably needs improvement in Mautic (either 2.x or 3.0). This is as a result of our incredibly fast-paced growth and our attempt to stay ahead of the curve. There’s no denying that as a result we sacrificed some of our “code beauty”. If you haven’t explored our integrations code existing in Mautic then I’d recommend taking a look. What has happened is understandable and yet inexcusable. We’ve added far far too much to the core package and not properly abstracted the integrations as they should be. This failure to decouple properly leads to several problems.
First, this makes plugin upgrades inextricably linked to a Mautic release. This means that at no point are we free to improve upon and release new versions of a particular plugin without waiting until the next version of Mautic is released. There’s no reason to continue this discussion as the problem here is blatantly obvious.
Second, the current integration situation adds bloat to core. There is no reason to bundle plugins with Mautic core while enforcing other plugins to exist in a plugin repository (or Mautic Marketplace) to be downloaded and installed by the user. All plugins should function the same way, reducing the overall Mautic footprint and providing a clear path for installation of desired plugins without extra baggage for unused or unwanted integrations.
While there is a path where integrations can be improved upon iteratively within the 2.x series, this is yet another factor to be weighed when exploring the potential of introducing a 3.0 release.
One final point to address when discussing existing challenges relates to the overall platform speed. I think it fitting to close this section with this point because ultimately this plays a major factor into the roadmap for Mautic in the future. Currently Mautic performs quite well in a variety of environments.
Mautic has been tooled very well to work for small to medium size databases and while the functionality services every business equally there were some limitations that began to emerge when working with large-scale database implementations. This had lead to a slowdown of various functions within Mautic and requires workarounds to improve.
Secondly, due to the entity hydration and Doctrine ORM implementations done within Mautic (partly to speed up release timing and create software faster) the overall architecture suffered. This isn’t immediately noticeable but does come to light with larger datasets and more intensive query objects (e.g. within campaigns or when creating complex segments).
Lastly, all of the above speed-related issues roll up into a degraded user experience. The goal has always been 300ms page load speeds within Mautic. While this may seem aspirational it does not necessarily mean its impossible. A rethinking of the underlying architecture gives us the opportunity to explore ways to achieve these aggressive goals and deliver an outstanding user experience.
Now that we’ve highlighted several of the challenges we’re facing in Mautic it’s time to explore how we solve them. This involves keeping an open mind and looking at every possible solution path. Some of these may be far-fetched, some may be irrelevant and some may seem overwhelming. The goal in this section of the document is to review all of them with an open minded approach.
I’m going to outline the four ways I see this being addressed and hope this serves as the beginning for further discussion. It’s also important to keep in mind that these solutions are not completely mutually exclusive. There is the potential for a combination of these solutions to be implemented for the final desired result.
There are both pros and cons to each approach and rather than attempting to highlight those options in this post I will leave that for either a future post or for group discussion. Instead I’ll merely outline what each solution entails so we have a better understanding of what each represents.
Re-write on existing framework
The first option we have is to rewrite on the existing framework. At first glance this sounds the most logical and least stressful of the solutions for Mautic 3. This would involve a significant review of the existing code and a harsh look at what should be re-written or even removed. At this time, there’s not a definite answer on the amount of work involved with a framework re-write on Symfony and this will need to be explored to have a better understanding of the level of effort involved.
Selecting a new framework
A second consideration at a major release point like this is to re-evaluate the framework that has been incorporated so far and determine whether it is the best framework moving forward. This also involves a great deal of work (obviously) as the code would need to be re-written. This is precisely why I suggested you keep an open mind at the beginning of this section. We need to objectively evaluate what is the best solution with all things considered. We must step back from looking at just the code but consider everything in its entirety that would be involved with something of this scale.
Another area where we must evaluate current Mautic 2.x versus Mautic 3.0 is the database architecture. Our existing structure has served us well but if we are exploring the undertaking of a 3.0 series we are defining a release where we have the opportunity to make significant improvements and/or adjustments to the database architecture as well.
Currently our table schema has presented a few problems (though minor) which may be served well by a refresh. This will allow us the opportunity to improve indexing, table columns, and even the overall structure of data. (Need an example? Currently we refer to contacts, however the database table is called leads, while this may seem minor it is a remnant of a speedy release earlier in the 2.x series that should be rectified).
API first architecture (headless)
The last item I recommend be considered as we explore this stage in our development cycle is a return to the topic of API’s. I mentioned this previously in the problems definitions section. We must reconfigure our existing structure and modify our existing product to be API first. This means we need to evaluate every endpoint, identify which are missing, and extract end-user code from the output (i.e. all responses should be JSON strings).
Mautic 3.0 is the first major opportunity we have to make this improvement. Regardless of the framework selected (after evaluation which we will discuss next) this is the time we should make the improvements to our API. We must make this a priority in order to ensure that Mautic is properly headless. (Interested in why headless is important? Let me know and I can make a separate post describing the value.)
Next comes the step where I need your feedback. I’m looking for end-user feedback, always, but more importantly I would like technical feedback on specific solution outcomes. This discussion has begun in the core slack channel of our Mautic Slack. I would encourage you to join the discussion there should you be interested. While opinions are welcome, those with use cases, specific data, and or use cases based on historical data will be given greater credence.
Let’s explore a few of the items to be handled by this evaluation process.
Whenever there is discussion over switching a framework there is usual an instant and visceral response. This response comes from a good place but often times is not backed with the correct factual information. As a result, during the evaluation process in order for everyone to keep “feelings” out of the equation (as much as humanly possible) I want to make sure we back up our opinions with benchmarks and statistics (again, as much as humanly possible).
I recognize that the best benchmark is one that involves our own software written in different frameworks and other factors all kept as control in order to provide a clean comparison. I also recognize this is highly unlikely and presents numerous challenges and as such we must do our best to mitigate these other factors from contributing to the result. This doesn’t take into account the impossible undertaking of writing the same code on multiple frameworks simply for the purpose of extracting benchmark data.
Based on this information it is deemed appropriate to find existing benchmarks for other platforms built on each of these framework at various degrees of scale and using those as a baseline for comparison.
Specific use case evaluation
Once we have some basic benchmarks we can begin to explore specific use cases and implementations. This is where we take the best of the best and begin to build out a plan for how the various pieces might work together. Again, the goal is a non-subjective approach to the information and presenting varying use cases for evaluation.
This should not be extremely time-intensive but rather a precursory step prior to the next phase where a proof of concept is mocked up.
Proof of concept
This step is often where I get most excited myself. Sometimes others may see me arriving at this step and not fully realize I’ve worked through all of the previous steps already. I trust in this particular instance we will make this journey together and share in the excitement of a proof of concept.
As a word of caution, the proof of concept is not a final or even functional application. We simply want to test our hypothesis and theories that we have drawn from the research, benchmarking, and use case evaluations. This is the point where we create code. We build out an example of what it would entail to create Mautic 3 using the solution as defined.
There are several key things to look for with a proof of concept. Code style, readability, implementation methods, and database architecture. This proof of concept should give us visibility into each of those areas as well as a good understanding of the implications of this solution as it relates to page speed and the API results speed.
Subjective item scoring
The last part of the solutions exploration involves scoring the results from each of the solutions identified on a number of criteria. This will be certainly challenging for our community based on the first word of the heading: Subjective. It’s never an easy task (and an oft avoided one) attempting to rank outcomes where the answer is not a clear black-and-white, yes-or-no. Instead we have to consider all potential benefits and detriments to each solution. We have to weight them according to their perceived merit and potential value.
There are a number of factors that contribute to the success of a solution and while I have highlighted the technical solutions first in this particular post there are others to be considered as well. I will be writing an additional post that will focus on the extraneous factors and how they affect the Mautic product either through a 3.0 release or implementing an update to the 2.x series.
So, now that we have this outline for what we are looking to accomplish and evaluate from a code perspective with a Mautic 3.0 release potential we need to begin focusing on how we best accomplish these goals. Here are the first three steps I am recommending we take as a community as we push forward with exploring Mautic 3.0
Organize a team
First, we need to organize an evaluation team. This should be a team with technical ability primarily as the majority of the items listed above are highly technical in nature. There will be a time and a place where the greater community will be able to voice their input and opinions and the subjective feedback from the community at large will be desired at that time. This initial team should be developer-centric given the tasks at hand.
Formulate an evaluation matrix
Once we’ve gotten a team organized and we have carried out the steps for the potential solutions listed above we can begin to draw some results and conclusions. The best way to do so is to compare an evaluation matrix where we can properly identify the pros and cons for each solution recommended. This will help to remove the subjectivity and allow us to focus on the best and most strategic paths forward.
When creating this matrix we will also consider additional items such as time to implementation and community involvement. In addition to picking the most technologically sophisticated solution we must also match that with the existing skills of our community and determine if we need to reach out to other communities for assistance as we seek to grow properly.
The evaluation matrix will not be evaluated at this point and a conclusion drawn but rather be the culmination of the work done to date and distilled down to a meaningful format which can be easily shared in the final step.
Prepare an RFC
The final step in this evaluation of the Mautic roadmap involves preparing an RFC for dissemination to the community. This is where we seek to get feedback, support and buy-in from everyone. We want to ensure that our community as a whole agrees with the decision made and more importantly agrees because they have received the proper factual information. This is where the evaluation matrix will offer a great deal of insight and information.
This will be a great milestone for the Mautic community as we continue to push the boundaries on marketing automation and the technology used in our software. We are capable and equipped for defining the future of the marketing automation space and this is our next big step in that direction. I hope you can tell the excitement I have not only for the outcome but also for the journey as we grow. I look forward to seeing what comes next!
Special thanks to Alan Hartless for his feedback to this blog post
April 24, 2018
Mautic and GDPR
One of the hottest topics circulating the internet these days is the upcoming legislation surrounding GDPR being put into effect on May 25, 2018. Companies of all sizes are closely watching what this legislation means and taking a hard look at their software to see what is affected. Given the hefty fines, this scrutiny and concern is completely understandable. Mautic, as an open source marketing automation platform and community also holds these concerns and possibly to a much higher degree than others. Our community has hundreds of thousands of businesses running Mautic, and our software is powering their marketing automation effort and customer data collection.
As a result, Mautic is of course highly interested in not only understanding, but also complying with any and all new regulations put forth that promote openness and transparency. Interested isn’t really the right word – more like /actively engaged/. We are dedicated to ensuring that our software not only complies but stands out as a model by which others gauge their own level of implementation.
Before I get too far into those details, let me give a very brief refresh on what GDPR means and what it represents.
GDPR, or General Data Protection Regulation, is a new European regulation that enforces the protection and accessibility of personal data for all European citizens. Read more
Four basic user entitlements
- Every individual is allowed to know what data is kept by any business; why that data is kept and for how long it’s stored by the business.
- Every individual has the “Right to Access” their own information and data.
- Every individual has the “Right to Data Portability” of their information (they can request a copy of their data as it’s stored.)
- Every individual has the “Right to be Forgotten”. (Request a business change and permanently delete any stored data)
Now you may be one of the shrewd ones and recognize a specific phrase in the original definition: that’s right the word European. But if you’re reading this from the US, you’re not off the hook just yet. Keep reading.
This new regulation applies to European citizens regardless of where they are located at any time. US companies must abide by these guidelines for any and all customers, contacts, accounts associated with the European Union.
There is one last aspect of the GDPR we need to consider before getting into some specifics. What is personal data? That’s right the GDPR is concerned with the data so obviously we need to understand what that data is. And this is where things get a little bit muddy. Here’s a short list of the most commonly recognized types of information that falls under this regulation.
- Online identifies (IP addresses, mobile device IDs, browser info, MAC addresses, cookies, account IDs, and other forms of system generated user identifiable data)
- Racial or ethnic origin
- Political opinions
- Religious or philosophical beliefs
- Trade union memberships
- Health data
- Sex life or sexual orientation
- Past or spent criminal convictions
- Genetic & biometric data
- Location data
- Pseudonymized data
Whew, what a list! Now that we have a bit of a handle on what the GDPR is about (at least at a high level) and you may be sufficiently uneasy about your current software I want to share how Mautic as a product is already compliant and continues to seek the best and most proactive approach in these new guidelines.
Based on the four principles listed above let’s look at an optimal Mautic configuration that complies with them. There are two options that existed for Mautic and my desire was to set a precedent for our community, our product and the entire marketing automation space. As I dug into this issue I met with more individuals in our community and in business than I could mention. My desire was to get a better understanding of the regulations and their implications myself. And I am excited to share with you the conclusions I’ve come to. And of course I’m always interested in more discussions on the subject and welcome the opportunity to chat with anyone that has questions, ideas or thoughts on this subject. It’s an important one.
Okay, with all that said, let’s dig in. As I mentioned there are 2 paths we can take. The real trouble lies in the uncertainty. I alluded to it earlier when I mentioned the “muddy” aspects of the data. There is a balance that must be struck. Mautic should be proactive and a leader in the implementation of these new guidelines. But time spent on unclear work, or without good direction is wasted and the time of our community developers is far too important to waste.
In order to make the absolutely best use of the developers in our community’s time; and in an effort to make the wisest decision in time and resources I believe the smartest strategy is to take a dual-prong approach. This is exciting because Mautic software can be easily configured for GDPR regulations today with just a few simple steps.
Instant GDPR Compliance
This dual prong approach involves an immediate step and a longer term software feature enhancement. The first step is quick and relatively painless. And with the implementation of a few simple changes to how you currently setup your Mautic instance you’ll be instantly compliant!
Here’s all you will need to do:
- The very first thing is to plan how to convey and accept explicit data collection consent, usually done through a focus element in Mautic, this step is potentially already being done in the case of cookie collection. As such you may only need to modify the language of your existing focus item.
- Configure two new segments within your Mautic software, name these segments, Request to be Forgotten and Data Requested.
- Setup a new form that allows an individual to submit their name/email and select the options they wish to submit (Request for Data, Request to be Forgotten)
- After each form submission associate them with the correct segment and take the necessary steps to either delete the contact from the database or export their record to a CSV.
- Notify the individual of the action taken.
One of the biggest (and simplest) mistakes I hear is people getting caught up in the thinking that this process needs to be instantaneous. While of course each request does need to be handled with expediency, nothing states it needs to be automated. To the best of my understanding, the above 4 step process gives you a GDPR compliant Mautic! Congratulations, you can sleep a little easier.
GDPR Mautic Software Improvements (Future)
Of course being compliant in this manner is only the first of the two-phase strategy. The second involves some modifications and improvements to the Mautic software. And while this is yet to be fully determined I can share a few ideas that have been circulating.
- New configuration section for GDPR.
- Configuration options that add the necessary acknowledgement checkboxes to forms automatically.
- A semi-automated contact deletion process
This is just for starters and only a few thoughts I’ve had as I’ve listened to some of our European community members share their concerns and their ideas. As I stated earlier I would love to speak with you and continue this discussion. Mautic is committed to being a leader in this regard and demonstrating to others how proper GDPR should be handled. We have the knowledge of a global community and the power of a flexible and open source development platform enabling us. Our software can be proactive and our software can demonstrate how others should consider GDPR compliancy. I trust this helps, join our Slack channels to learn more and make your voice heard.
April 13, 2018
Open But Not Inclusive
This week I attended DrupalCon in Nashville, TN. I always enjoy open source conferences and this event was no different. There were hundreds of sessions available over the 3 day event and it’s always tricky to navigate the feeling of “information overload” when attending a multi-day conference like this.
One of the tricks I’ve learned over the years of attending these events is to take one session slot each day and not attend a session. Instead I find a quiet location somewhere and jot down my thoughts on what I’ve been hearing and learning. This helps me to keep from getting conference brain where I’m sitting in a session but not hearing anything. This also gives me a chance to catch up on other messages so when I /am/ in a session I can give it my undivided attention.
I’d like to share with you is the result of one of those reflection sessions. This nugget of greatness came from the opening keynote on Day 2. Steve Francia, @spf13, was sharing his story and it was full of helpful information, anecdotal advice, and stories from his personal journey. It truly was an amazing keynote. As he spoke there was a few slides in particular he shared which caught my eye and attention. They specifically addressed an issue I am constantly aware of with the Mautic community.
You’ll have to forgive my sketching, and trust me when I say his slides were much prettier. But I imagine you’ll get a fairly good idea of the concept. Not to mention, if you are that interested; you should have attended!
Here’s the basic concept: Open NOT Inclusive.
The idea was one that Steve mentioned he discovered while working with Google and the Go community. What he saw was that the core team (Google) was doing all the contributing to the code and the community was observing and consuming without being actively included or taking active leadership roles. As a result the true power of the community was left untapped and the internal team was a limiting factor.
I was struck with the similarities to the Mautic community and as you can tell from my sketch I self-identified with our team in a similar fashion. At this point I found myself agreeing with Steve’s problem statement and as such was eager to see what he shared next. Below is again my representation of the slide that followed.
Steve offered a simple solution. Well, it appears simple, but the implications are of course much greater. The suggestion as outlined above involves Distributed Control – when the community is able to make leadership decisions and assume roles of responsibility the dynamics change. This seemingly obvious change to /inclusive/ gives a sense of ownership to the community. It makes the community truly empowered and in control of it’s own destiny. What a fantastic and exciting future.
While I believe that the Mautic community is working hard to assume positions of leadership and my intent is to see this growth occur as soon as possible this served as a valuable reminder to me what we are all striving for. Steve pointed out that the Drupal community was an excellent example of this inclusive open community functioning properly and looking around at the thousand or so in attendance I would have to agree with him. I look forward to the Mautic events in the future when we can say the same thing and demonstrate it with the many community leaders taking an active role in the future of our project.
That’s all for this post, but I will continue to share my thoughts from my reflection sessions in the near future. In the meantime, let’s not forget this valuable lesson and keep striving to make Mautic the most amazing community it can be.
March 20, 2018
Market Smarter Not Harder
I think a lot about what’s coming next in the world. I focus a good bit of that time on the area where I spend most of my waking time – Mautic and marketing automation. When I set out to create Mautic I wanted to create a marketing automation platform that had never been seen before. I wanted to give the world the tools and the power of a platform that not only excelled in feature and functionality compared to existing proprietary products but also did so in a revolutionary way.
I am excited to see and hear the growing and continual positive response that Mautic receives. The reviews keep piling up and the compliments speak to the fact that we are accomplishing our goal (notice the verb tense? Active. Because we’re not done yet). If you haven’t had a chance to explore the Mautic marketing automation campaign canvas then you’re really missing out.
What we’ve created is something that was more robust, more functional, and quite honestly more beautiful than anything marketers had ever seen before. And that’s not just marketing speak. The blank white canvas you start with is a breath of fresh air. From here you can create a simple or complex marketing campaign with the ease of dragging and dropping items onto the page. It’s just like sketching on a whiteboard (and we all know how much fun that can be).
But this is only the very first step in our marketing automation journey. There is so much more to be done. We have to keep digging deeper and we have to continue to explore what should be done with marketing automation and doing smarter marketing.
What follows are my ideas. They are incomplete, they are my sketches and my thoughts. I want to engage you in my future-looking focus. I want to encourage you to expand your mind and think more about what the future might look like.
Let’s talk about old marketing first. I know I’m calling this old marketing but unfortunately the oldest of these sketches is what some current marketing automation platforms still sell today. Mautic v1 was the revolutionary marketing automation platform our community created over 2 years ago. Today it is still one of the most talked about aspects of our platform.
So, with all that hype why am I considering V1 and V2 to be outdated? Let me explain. Marketing automation should be automated. We all agree with that concept. The above marketing campaign solved some of the problems with marketing automation but not all of them. Mautic did some amazing things with multi-channel messaging. We also created some really advanced campaign canvasing that allowed marketers to send those segments down a variety of paths with different channels for communication.
But there’s a fundamental piece that has been overlooked. We also all agree that marketing automation should be personalized. With that in mind why do we continue to do marketing in groups? (By groups I mean of course segments)
This is where I believe the next step in marketing need to be realized. Let me elaborate.
First, I want to be sure that I don’t think I’m suggesting something new that’s never been thought of before. There are many smart people that have done bigger and better things before. I want to make it a reality. I believe Mautic and the open source community is capable of making those ideas a reality. The above sketch is what I believe the future of marketing automation looks like and in the next 6-9 months I am confident the Mautic community can achieve this.
Okay, now what does it look like? Let’s get real. Instead of the marketer having to create these elaborate paths that segments or groups of contacts have to navigate together there should be a more personalized route Here’s what that looks like broken down.
Marketers should instead create marketing messages which are a number of variants of the same message created for several channels (e.g. email, sms, web push, mobile notification). These variants are collectively called a marketing message. The marketer outlines an objective and success for each message. Finally, the marketer then creates a number of these marketing messages. After creating these messages the marketer defines what success for the campaign should look like. Success does not necessarily mean 100% completion of every message. Instead a marketer may decide upon a number of outcomes based on various percentages of completion.
This may sound mildly familiar and somewhat similar to existing marketing but here’s where it gets different, very different. Marketers shouldn’t have to market to entire groups as one; better that each contact received a personalized marketing campaign based on their particular specific interests. Mautic V3 does this.
Because Mautic v3 creates customized journeys for each contact based on their preferred contact channel. In addition to sending the message on the preferred channel, Mautic also accomplishes one other important marketing objective: right time.
I know, it sounds a bit like a marketers dream – right time, right message. But that’s exactly what Mautic offers and we’re able to do this because we’ve been planning for it all along. We launched version 1 with multi-channel messages. We released version 2 with the ability to create marketing messages as well as a preference center for contacts to select their preferred channel. From day one we’ve been carefully creating a marketing automation solution that is world-class and second-to-none. Mautic version 3 continues that journey and brings about the next step in amazing marketing automation.
January 3, 2018
The MIRROR 2017
Well recently I wrote about my New Year’s Resolutions and I admit my post was a bit of tongue-in-cheek and felt it only fair to share something with a bit more substance. I figured the best way to do this was to share something meaningful which I spent a significant amount of time writing. This was meant for internal use only but in the interest of openness and transparency I’m going to share with the community.
Every end of year provides an opportunity to reflect back on the previous 12 months and identify the successes and the stumbles that occurred. A good look at oneself is hard but extremely helpful. Knowledge is power and if we have a good understanding of what we truly know we can be more powerful. Honestly there’s few things worse then to be “in the dark” about something and if we don’t know what happened in Mautic or what others are doing then we are completely clueless.
Below is a document I created that will help you understand every aspect of Mautic. If you’re involved in Mautic then this document will give you a great review over what all has been done in the past year. If you’re not yet a part of this incredible community then maybe this deep look at every aspect of Mautic will help you understand why Mautic so special. And even better this may give you some ideas on how you might get involved in the Mautic community.
I will probably comment about various aspects of this doc in future blog posts but for starters I’m merely going to share the doc. Enjoy the reading!
December 21, 2017
Re-Launching Mautic Meetups
Recently I received an email letting me know that my subscription to Meetup.com had expired and as a result the Meetup groups for which I was listed as organizer were now listed without an organizer and in danger of being shut down.
This got me thinking; if I had a problem with keeping up with one more subscription then I imagine there were others as well. Digging in even deeper I discovered there were other Meetups not forming simply because of the costs associated with the existing platform. As a result Mautic was fighting for consistency and a unified platform for the community merely due to the tool being used! Our community was limited from growing properly not because of the community but the tool we were using. Quite contrary to the very reason we were using the platform!
This gave me an idea. What if there were a better way? And just like that a new Mautic initiative was undertaken. I reached out to a few of the community who I suspected would be interested in working on building something better and we got to work.
Identifying Our Needs
The first thing we knew we needed was to clearly identify what we needed from a group networking and meeting solution. As it turns out there is not necessarily a long list of requirements that we simply must have in a tool.
Our current groups were semi-organized, gave people a way to join them, share upcoming event details, and in some cases share photos from past meetings. That doesn’t sound like something too difficult to find in a solution. Oh, and there was one more objective that was ranked quite highly on our list. We were intent on finding a solution that held to the same core beliefs and standards that Mautic holds. This meant we wanted an open source solution. Based on the list of our needs we believed this was completely doable.
Aside: I believe strongly in using open source solutions. I do so when the tool is the best at what it does and performs better than other solutions available. In other words, open source is not (and should not) be the sole deciding factor when selecting a tool.
Evaluating The Alternatives
The next task we undertook was to evaluate the various solutions available keeping in mind the list of requirements we wanted to see. The list was surprisingly shorter than anticipated. There was the obvious incumbent that we had used before and we knew the shortcomings associated with that platform. Then there were a variety of hybrid solutions where we could make something work if we cobbled a few different tools together or if we chose to neglect different aspects from our requirements list. That sounds rather problematic especially when our list is rather short and honestly quite simplistic.
Finally, after some thought and much review we settled on something far easier and quicker than we anticipated. With the help of a plugin for our existing website we could extend our current CMS to enable groups. This met the needs we had, increased our community opportunities, and finally much to our delight was an open source solution.
Once the decision was made the process of implementing was undertaken. This solution encouraged us to think about two more questions we hadn’t initially expected. The first question was quite relevant to our current initiative and the second question was far, far more existential.
- What do we call our community meetings?
- What is the main purpose for Mautic.org?
I’ll answer them in reverse order. The second question came about because we recognized that with the integration of groups directly into our website perhaps now was a time to evaluate the purpose and reason for our main website. What purpose does it serve and how does it enable our community to be bigger and better? Our current goal was to identify a way to enable our community meetings and not answer such a large question but there are a few minor steps we could take to better prepare ourselves for the future so when the time came to answer this question we would be prepared and ready.
The first question was one we new we had to answer and wanted to create something that resonated with our community and also hat-tipped to the many other open source projects that had paved the way for our success. And of course, it never hurts to create a name that’s unique and special to our community.
I am excited to share that after only a little deliberation we chose to call a community meeting a MautiCamp. These MautiCamps are a way for our community to meet in person at cities around the world on a regular basis. MautiCamps are organized and lead by local volunteers. Our existing MautiCamps are an incredible list of locations literally around the globe. It’s amazing how fast they have grown even in spite of a difficult community platform. I believe that this new open source platform built directly into our website and available to everyone completely free will make our community grow so much faster.
There are many more ideas and suggestions related to our MautiCamps that I want to share. Ways to make them even more successful and ways to empower volunteers to get involved. I can’t wait to share more. If you are a current MautiCamp organizer I would welcome the chance to talk with you, get your ideas about what’s been working and what needs improvement and share some of my initial thoughts for your feedback.
If however you are not yet in a MautiCamp or don’t see a MautiCamp close to you, or focused on a topic you’re interested in, then I have a challenge for you. Why not organize one yourself? There are resources available (and more coming as I suggested) to help you create a vibrant local community. You’ll be amazed at how many others may be close by already and interested and what better way to find new friends, learn new things, and grow your business then through the awesome power of Mautic.
December 16, 2017
Upcoming Mautic AMA
2017 is drawing to a close and it’s been a whirlwind of a year. There’s been so much going on in the Mautic universe it can be a bit overwhelming. Whether you’ve been around for the entire ride, or just joined us I have no doubt that you may have a few questions about things.
As you may have begun to notice I’ve been ramping up my efforts on sharing information. One of my focuses as we close out this year and start the next year involves how to empower more people in our amazing Mautic community. To that end I have been working on the best way to share information, organize my thoughts, and help get everyone on the same page in terms of Mautic: where we are, where we’ve been, and possibly most importantly – where we are going. I’ve shared several posts recently on my blog (here, here, and here) which give a few insights but I believe there are even more ways I can improve. Because I think there are probably still questions outstanding that haven’t been answered yet.
So, in order to help with that I am preparing to do something for the first time in Mautic history. I am excited to announce our first ever AMA (ask me anything). This will be an opportunity for you to ask your questions directly and hopefully get immediate answers. There’s general guidelines for the session and of course any deep technical questions or bugs you just want solved are not really the purpose of this time. To put it bluntly I won’t be “live fixing” anyone’s website. 🙂
However, questions about how Mautic should be used, ways to get involved, questions about the roadmap, our community future, leadership structure, GitHub projects etc…these are all welcome topics and I will do my best to give you good, clear, concise answers. And I give you my word, if I don’t have an answer – I’ll be honest enough to tell you I don’t know and point you to a resource that might be able to help.
The goal of this AMA is to ensure our global community, and you as an individual, feel confident in what we’re doing and also where we’re going. I hope this will be a fun, enjoyable and informative session where we can all learn and improve.
And lastly, if all goes well I hope we will hold more of these in the future. I’m not going to dig into specifics about what to expect (Remember this is our first one, we’re going to be learning as we go). But here’s what you need to know now:
What: Mautic’s First Ever AMA
Where: Mautic’s Slack Channel – # ama
When: December 21, 2017
Time: 10:00AM EST (The World Clock Meeting Planner – Details)
What To Bring: Your questions!
See you there!
Oh, and if you can’t make it you can still send in your questions.
December 13, 2017
Standardizing GitHub for Product Management
GitHub is a fantastic tool for organizing code, handling issues, and tracking feature requests. Mautic has always used GitHub for its code repositories and more. But there are struggle that come from tools like this and without proper organization or structure it can quickly make a project become a chaotic jumble of questions, feature requests, and code. A lack of standardization destroys an otherwise useful system.
I am proud of the organization that Mautic has around issues and the use of labels. This has historically been something we’ve done somewhat well. We’ve also made extremely good use of the basic code repository and release functionality. You can see this well-organized approach by diving into the Releases tab and noting how every release going all the way back is documented and tracked. It’s refreshing to see things like that and speaks to the consistent attention to detail we’ve worked so hard to maintain.
But I firmly believe there are always things that can be improved and our GitHub usage is no different. So I sat down and looked at our repositories and began exploring ways we could improve our organization and structure around our already amazing product.
Improving and Explaining Labels
I shared at the beginning that Mautic is very good in its use of labels as it relates to issues and pull requests. But I think sharing what those labels mean and how they are applied is helpful as we discuss a standardization of our GitHub account and organizational structure. Plus, I’m not sure it’s been clearly outlined recently how those labels are used.
Here’s a current list of our existing GitHub labels, when they are applied to issues, and how they should be interpreted.
- Backlog: Applied to any issue left in an open state longer than 6 months, not automatically applied yet but will be in the future.
- Bug: Applied to issues directly related to a bug in the production code.
- Code Review: Applied to issues that require additional review of code by core and community developers before merging will occur.
- Duplicate: Applied to issues that have already been submitted. New issues will be closed in deference to older ones.
- Feature Request: Applied to new features or modifications to functionality that is different than originally intended.
- Has Conflicts: Applied to PR’s mainly that conflict with other parts of the Mautic codebase. Must be resolved before merging.
- L1: Applied to issues where the fix is deemed lowest level of knowledge to create. Alternatively applied to PR’s where the testing is considered minor in time and intensity. Considered a Level 1 item.
- L2: Applied to issues where the fix is deemed to require a moderate level of knowledge to create. Alternatively applied to PR’s where the testing is considered moderate in time and intensity. Considered a Level 2 item.
- L3: Applied to issues where the fix is deemed to require a significant level of knowledge to create. Alternatively applied to PR’s where the testing is considered significant in time and intensity. Considered a Level 3 item.
- Needs Automated Tests: Applied to pull requests submitted without the appropriate unit tests. Every pull request requires unit testing of code.
- Needs Documentation: Applied to pull requests submitted without the appropriate documentation. Every documentation requires accompanying documentation.
- P0: Applied to issues considered critically important to resolve. These issues are ‘showstoppers’ and ‘break’ the entire Mautic system.
- P1: Applied to issues considered detrimental to Mautic functionality. These issues are important but do not stop day-to-day operations.
- P2: Applied to issues considered annoyances to Mautic functionality. These issues are high priority to fix but do not restrict usage.
- Pending Feedback: Applied to issues or pull requests that require further information or discussion before being added into work queues or testing.
- Pending Test Confirmation: Applied to PRs that still require a second successful test confirmation. /Every Pull Request requires 2 successful +1 tests before merging./
- Ready To Commit: Applied to PRs that have been tested and are ready to be merged.
- Ready To Test: Applied to PRs that have been submitted with completed code and are ready for community testing.
- Translations: Applied to issues that are related to translations. /All language translation strings are handled by Transifex/
- User Experience: Applied to issues and PRs that are related to how the end user uses Mautic and experiences the platform.
- User Interface: Applied to issues and PRs that are related to the user interface directly, typically these are cosmetic problems.
- WIP: Applied to PRs that are not ready for testing. These are Work In Progress and represent work actively being done by another individual.
I recognize that list feels long and possibly a bit daunting but I trust the somewhat exhaustive explanation will help clarify how Mautic applies labels to issues and pull requests and makes your life a bit easier as you contribute to the Mautic platform. Other labels may be added in the future either for temporary usage or as additional labeling is needed.
Improving Feature Requests
The way that Mautic handles feature requests is quite simple at the moment. We have a label marked Feature Requests which is applied to every issue created that represents a new feature request (See I told you it was simple.) There are a few problems with this basic approach to feature request tracking. First, this drastically clutters and increases the total number of “issues” on the project (notice the screenshot above – 728 Issues). This number actually includes 314 Feature Requests and inaccurately skews the number of issues. Second, with the current system feature requests are lumped in with every other issue in the system and it makes it exceedingly hard to identify what features have been requested and which are the most popular. This leads me to the first standardization I am recommending we implement in GitHub.
Standardize Feature Request Voting
Moving forward I recommend that the somewhat new “reaction” feature in GitHub be used for feature voting.
Specifically, only the following two reactions should be used for feature request voting: 👍 and 👎. A thumbs-up indicated a +1 vote on the feature and a thumbs-down indicates a -1 vote on the feature.
This will then allow anyone to quickly view the issues on GitHub and with the proper query be able to see a list of feature requests sorted by popularity. To make it easier for you here is the exact link you can use:
As a bonus side effect of this standardization we will be able to programmatically pull this list of issues via an API and allow us to inject a Top Feature Request List in other locations as well.
Improving Pull Request Testing
The second area where I think a bit of standardization may be helpful involves the testing of pull requests. Currently there is a core team in the community managing the testing and committing of pull requests. This ends up appearing to be a bit unclear and not as visible as it should be to the community as well as not demonstrating a clear path for community volunteers to grow into various leadership positions. The core team is open to community members who demonstrate their ability to properly test and merge code contributions. However, the privilege of that responsibility has to be earned through a building of trust. That trust can’t be established without some method of consistent demonstration of personal reliability.
This brings about my second recommendation for GitHub standardization.
Standardize Pull Request Testing
Our Mautic community needs greater empowerment as I shared above in playing an active role in which pull requests are merged. Our volunteers also need the opportunity to grow into greater leadership roles and become critical parts of the core team. This means community testing of pull requests. Specifically, a +1 listed as a comment on a pull request implies that the developer has tested the PR in accordance with the test procedures listed in the pull request description.
Alternatively, adding a -1 comment signifies the developer has followed all the same steps and procedures outlined in the pull request but did not find the fix to successfully solve the issue.
Notice in the above comment additional text was added (this is acceptable as long as the comment begins with the appropriate +1 or -1 designation.
And you guessed it, as a bonus we can programmatically use the comment text to extend the use of GitHub to other systems and improve communications as well as automations.
It may not sound like a terribly fancy system, or even a huge difference in how we manage our GitHub account currently but these little improvements and standards in how things are managed make our entire development process better and more streamlined. And the more organized we are, the more efficient we can be. The more efficient we are the better and faster we can grow.
You now have all sorts of new knowledge and insight into Mautic development, go find your favorite feature requests and 👍!
December 11, 2017
Creating The Mautic Credit System
Recently I published a blog post Recognizing Mautic Code Contributors. If you haven’t read that post I’d recommend taking a few minutes and reviewing it before continuing. I want you to review it because there are good things and bad things in that article. While any level of tracking and metrics is better than none there is always room for improvement.
In fact, one of the things that I have been most focused on in recent months has been properly tracking volunteer activity across Mautic. As you read Github does provide some nice metrics to allow for some level of acknowledgement and recognition (purely as it relates to issues and pull requests) but this is such a fractional and minor view of the Mautic community I knew we still had a long way to go. I also knew my good friend Dries Buytaert recently shared a blog post about the credit system implemented in the Drupal community and this reminded me of the work that had already been done in this area. (What better way to build a system then on the shoulders of a giant.) And so we began crafting a Mautic credit system.
The Idea of Merit
As with any system we wanted the Mautic contributions to be recognized in a special and unique way. After consideration of both fun names as well as common names we settled on something that made logical sense and also had a fairly nice benefit of being an ‘M’ word. In the Mautic community a volunteer can earn Merit through a number of different ways. Below I’m going to outline some of the ways a community member can earn Merit.
Community Involvement: GitHub
We wanted to look at community involvement across a wide range of metrics beyond just GitHub, but at the same time recognized that there was much more activity going on in our repositories besides just issue creation and pull requests. And so we set out to create something special. I’d like to share with you some of what we’ve created so far and then outline what we plan to create next. Please keep in mind that everything is still very much in a beta stage and changes will continue to be made as the system evolves.
In the beginning we recognized those volunteers who contributed issues simply as a matter of volume and frequency. With the introduction of Merit we have taken that rather rudimentary beginning and created something much more intelligent. A volunteer can receive Merit based on a number of factors when opening, editing, or closing an issue. These factors include the level of difficulty of the issue, the thoroughness of the issue report, the adjusted status of the issue, the number of comments on the issue at the time of the status change and other factors. Sounds incredible? That’s because it kind of is.
Similar to issues the early days for pull request attribution and recognition revolved almost entirely around the creation of a pull request. The Mautic credit system again allowed for a fairly massive improvement to this basic implementation. Mautic contributors can receive varying amounts of Merit based on complexity of the pull request, the creation, and subsequent merging of the pull request (and other factors as well).
The very nature of comments on issues and pull requests is a tricky one as this can be the most abused area within a credit system. Volume of comments does not necessarily equal quality contributions. Merit attempts to intelligently recognize the value that a comment brings to the issue or pull request. I will be the first to point out that this area will require the most refinement and improvement as we learn what represents value. Merit will get better over time.
Community Involvement: Forums
But I knew we couldn’t stop with just the code in Mautic. In fact, this was only the beginning. The second area where Mautic needed to create some reward system was in the forums. Just as with the GitHub facet of the community I was interested in gaining a much more detailed understanding of how the community was growing and improving as it relates to our forums. And as I have shared before – the better our knowledge the better equipped we are to improve.
In the Mautic Credit System we provide Merit for a wide range of activities. One of the most obvious ways to gain Merit through the forums is by creating a post. Each post creation gives a certain amount of Merit to the forum poster. While this is the most obvious way it is also the lowest weighted method (again due to the nature of determining value associated with a specific post).
Forum Post Solutions
The greatest way to earn Merit through the forums is by solving another posters question. When a forum post is marked as a solution Merit is credited to the solution’s author.
Community Involvement: Slack
There is also value to the Mautic community knowing the activity of volunteers as they engage in conversations within the community. Volunteers in Mautic receive Merit when they log in to the Mautic Slack team, when they log in for consecutive days, and when they login and post messages to channels. As with other ways of gaining Merit the Slack engagement method is a constantly changing algorithm and will improve over time.
Community Involvement: Meetups
Mautic Meetups are offline events but they can still be (and should be) a way for community volunteers to gain Merit. Clearly a community member that attends a Mautic Meetup, or even better organizes and leads a Mautic Meetup should receive Merit for their involvement. The Mautic credit system accounts for these events and offers Merit for them.
Community Involvement: Translations
Translations in Mautic are a huge part of our community and an aspect that makes Mautic truly impressive. As a result we wanted volunteers to be rewarded for the value their translations bring to Mautic’s global initiative. We use Transifex for managing language translations and the Mautic credit system will be deeply tied into this platform so Merit can be given based on involvement on translations as well.
New strings added to an existing language, language string reviews, new languages created, and language moderation are all parts of the Transifex translation system that are monitored for Merit.
Community Involvement: Blog
Mautic volunteers are active in many parts of Mautic and writing articles that are published on Mautic.org is an additional way to help share the Mautic name and be involved in the community. As a result Merit can also be earned for blog article contributions.
The Future of Merit
As you can probably begin to tell from the above list; Merit is a constantly growing and improving concept. I don’t claim it to be perfect and I certainly don’t think the work on this new Mautic credit system is complete. Every day brings new challenge as well as new opportunities. I have numerous other ideas where we can implement Merit. The beautiful thing about our current technology is the seemingly never-ending list of APIs.
And so the Merit system will continue to evolve and grow and improve. We will learn which of our existing systems needs to be tweaked and make changes based on our understanding and how the community grows.
Merit Implementation Team
Because openness and transparency is a cornerstone principle within our community and because (as I just shared) the future of Merit involves constant improvement and growth, a team is being created within the Mautic community help establish this initiative and make the result something the entire Mautic community can be exceptionally proud of.
Merit Open Source
You had to know this last paragraph was coming right? Mautic is one of the leading open source companies in the world. We build incredible open source software and we distribute it to the world for everyone to benefit from. Open source is in our DNA. Open source is how we see the world.
We are building the Merit platform as an open source tool so that other communities in the future can also implement what we believe will soon be one of the most robust volunteer recognition system ever built.
If you’ve ever experienced the Mautic community or used the Mautic marketing automation product you will already know that the products we create and that our community is responsible for are beautiful, sophisticated, powerful and yet easy-to-use. The Merit system is no different. This means it may be a little while before we tag a version 1.0 but it doesn’t mean we won’t be sharing our progress and incorporating feedback along the way.
Next Steps with Merit
I am excited to lead the Merit Implementation Team and help organize volunteers around this effort. I shared in the beginning of the post that we had already begun this initiative and I will be sharing frequent updates on this blog as progress is made. If you are involved in the Mautic community you will begin to see signs of Merit appearing in the various channels I outlined above. And finally your community member profile on Mautic.org will begin to showcase all your volunteer work.
I hope you will be as excited as I am about Merit as you begin to see the system we’re building and the ways it will recognize the invaluable contributions of our volunteers. Mautic is one of the best open source communities in the world and now we will have a practical and specific way to recognize and reward the great volunteers that make it up.
December 8, 2017
New Themes in Mautic
Unique landing pages and email templates are incredibly popular and critically important to most businesses. These are ways for the business to make an impression with their audience that stands out. They want to create a look that is specifically their own. And they want to make sure their brand is represented across all of their marketing efforts. Whether it’s a landing page, or email and form, or even something as simple as a notification Mautic wants to make that seamless with the rest of the brand.
Mautic has always been acutely interested in creating a platform that allows each marketer and each business the opportunity to create their brand experience across all their digital media.
From the very beginning of Mautic we created a way for there to be an infinite number of custom themes within Mautic. These themes included all of the elements I listed above. We wanted the marketer to have complete control over the entire marketing outreach; regardless of channel. This meant creating a way for marketers to use their own themes. And a way for developers and others to create additional themes and add them to Mautic .
Extending that even further there’s an opportunity in the future for community to create and then share their theme packs. This concept is nothing new to anyone coming from an open source community in the past (content management systems such as Drupal, WordPress and Joomla are notorious for their plugin systems and marketplaces). In Mautic we do things a bit differently since these theme packs offer more than a website theme or template. But the underlying principle remains the same.
The creation of this marketplace is the topic for another blog post which I’ll publish in the near future (hint: we’re getting things ready and we need your help!) For now I want to turn our attention back to themes and share with you some exciting news.
In the 2.12 release of Mautic we are including additional core themes. Keep in mind that usually themes are added to core only once in a great while. And this will be the case for Mautic in the future too, however, 2.12 is a special release. Since we have not yet launched our marketplace and there are so many using Mautic (Over 100,000 now using Mautic) we wanted to make sure we had incredible default themes available for everyone use. And we wanted to improve on the ones that were already existing in core. I’m so excited to announce that we will be including not just one theme, but four new themes in Mautic 2.12.
I won’t keep you waiting any longer, below are a few screenshots of those themes. But first here are a few things to keep in mind.
- Every theme is fully responsive and works on all device types
- Every theme includes layout and design for emails, forms, and messages
- Every theme is completely customizable
- And lastly: Every theme is completely free and available for immediate use
And now, check out these new themes:
These are some beautiful, responsive Mautic themes. Marketers will be able to take these four highly flexible and customizable themes to build a unique and special digital experience. I couldn’t be more pleased with these themes and I am thrilled to see them included in Mautic 2.12.
I’d like to offer a very special note of thanks to GaberNeighbor · GitHub for his time and creativity with these themes. And this gives me the chance to encourage others to do the same. Mautic is a great way for designers and developers to share their creative talent. Themes in Mautic are seen and used by over 100,000 businesses. Creating themes is an exciting way to get involved in Mautic.
If you’re interested in getting involved in this way be sure to check out the Mautic #design slack channel and read the Mautic Developer Documentation for other helpful theme creation resources.
December 6, 2017
Improving Mautic Query Speeds
Creating robust applications capable of scaling to handle millions of records in any industry is difficult. Often as a startup there is a focus on speed and agility in development, but that same speed comes at a cost. Fastest development does not always equate to best development. In the startup life we are focused on creating a product people want. Actually, scratch that, we start by thinking about creating a product people want; but in reality we quickly realize we have to create a product that people will love. And we have to do it immediately.
And whenever a startup moves that fast they focus on today’s issues. Most of the time that’s valid. Very rarely does a startup have to face massive scale problems. Those are tomorrow’s problems solved another day. Mautic was no different. We built our Minimum Lovable Product (MLP) and began an incredible journey. The speed at which Mautic accelerated while exciting is not (or should not be) surprising. Powerful free software performing tasks never before offered as an open source downloadable product is certainly something to be excited about. And the world was excited. But this acceleration has happened to others before and so in that sense Mautic wasn’t alone. Which means the problems and challenges we have faced (and the solutions we arrived at as a result) are also not unique.
I don’t say any of the above as an excuse, but instead as background. An introduction because Mautic developers are some of the finest in the world. My previous post recognizing the Mautic code contributors attests to the work they have done and continue to do. But there is a different type of thinking that comes into play when taking software to the next level. Things like query language becomes critically important. Here’s an actual example from Mautic.
$q->from(MAUTIC_TABLE_PREFIX.'leads', 'l') ->andWhere(sprintf('NOT EXISTS (%s)', $dncQb->getSQL())) ->andWhere(sprintf('NOT EXISTS (%s)', $statQb->getSQL())) ->andWhere(sprintf('NOT EXISTS (%s)', $mqQb->getSQL()))
This partial query is used whenever you attempt to load up a list of emails in Mautic. Normally this isn’t a big concern and the query above would have no issues. However, when dealing with a large number of contacts the above query results in significant slowdowns. What’s the solution? Well in this specific case,
howlinghuffy (Nick Hough) · GitHub came up with a rather simple and seemingly equivalent query that yielded drastically different results.
$q->from(MAUTIC_TABLE_PREFIX.'leads', 'l') ->andWhere(sprintf('l.id NOT IN (%s)', $dncQb->getSQL())) ->andWhere(sprintf('l.id NOT IN (%s)', $statQb->getSQL())) ->andWhere(sprintf('l.id NOT IN (%s)', $mqQb->getSQL()))
That’s right, by replacing
NOT EXISTS with
NOT IN the query yields the exact same results. But from a speed perspective the results are far from the same. Before the modification when Mautic managed 500,000 contacts this page took approximately 200.5 seconds to render. After the query was changed the same query takes 1.04 seconds. That’s right, 200 seconds down to 1 second. That’s a 200x speed improvement.
Are there other queries within Mautic that should be evaluated and re-written? Absolutely. And the Mautic community is best equipped to handle this challenge if they know what they are looking for. This was one example. Let’s go find others!
December 5, 2017
Recognizing Mautic Code Contributors
Recently I decided to do a little digging into Mautic’s contributor logs to see who was doing big things when it comes to Mautic’s marketing automation code. I also wanted to compare how we compared 2016 to 2017 since we’re fast approaching the end of 2017. It seems hard to believe that we’re almost ready to close the book on another year!
I thought the best thing to do would be to look at a variety of stats first comparing different metrics between last year and this year. One thing that I believe is very important to mention at the beginning before we start looking at specific numbers is how much of Mautic community growth can NOT be measured by a number or a specific number of lines of code. The following metrics simply report on one aspect of the overall community and should in no wise be considered indicative of the community as a whole (good or bad). The code aspect is merely one facet of our community.
Number of Developers
The number of developers contributing code to Mautic can be viewed in several different ways so I’ll share a few of them and let you draw your own conclusions.
This first graph shows the growth of developers and reviewers over the past two years. As you can see we have a steady increase in the number of “contributors” over the past 24 months. This time period covers Mautic versions 1.2 through 2.11 and does not include the month of December of this year, 2017. There are significantly more reviewers than developers but this is expected and both are still considered contributors as Mautic requires reviews to be done before a pull request can be merged. The Mautic company is identified by the dark grey in the chart as well. You can see that although proportionally Mautic the company (MCO) contributes the greatest number of developers than other companies there are increasingly more and more months developers and reviewers from the community.
There is an important side note that should be considered when reviewing the number of contributors and the relationship between MCO engineers and community developers. The amount of code contributed by MCO engineers comprises approximately 82%. This means that although the number of developers in the community is increasing MCO is still the largest single contributor by a significant amount.
But just to give a bit more recognition I’d like to share a specific list of the top 20 individuals who have contributed code to Mautic in the past year. This list isn’t exhaustive; there are many more (as the stats above demonstrate). But these individuals deserve a special specific callout for their work. Here is a list of the top 20 individuals and the number of lines of code they have contributed to Mautic.
- alanhartless*, 91179
- escopecz*, 55362
- dongilbert*, 39954
- mqueme*, 33581
- stollz, 22008
- virlatinus*, 20850
- GaberNeighbor*, 12113
- Maxell92*, 10950
- kuzmany, 6768
- thecodeine, 5525
- drmmr763*, 5287
- npracht, 3783
- MarkLL, 2541
- mikegillis677, 2309
- Woeler, 1546
- shulard, 1439
- jordan8037310, 964
- isleshocky77, 750
- lightweight, 678
- Dreiser*, 634
But code contribution is more than just lines of code. (I’ll be the first to suggest that the number of lines of code may be a terrible metric for judging activity…more on that later). So here is a second list. This list recognizes the top 20 individuals and the number of merged pull requests to the Mautic code. Again, they each deserve recognition for their contributions.
- alanhartless*, 628
- escopecz*, 390
- mqueme*, 150
- dongilbert*, 98
- kuzmany, 83
- virlatinus*, 76
- mbabker*, 37
- MaxWebmecanik*, 27
- drmmr763*, 23
- Dcoutelle, 18
- isleshocky77, 16
- arulrajsm28, 12
- phil-davis, 11
- shulard, 11
- SamWebmecanik, 11
- chandon, 10
- jordan8037310, 9
- Woeler, 9
- npracht, 9
Comments & Pull Requests
The second chart I would like to share with you is in relation to the overall comments and pull requests that the Mautic codebase has received over the previous 24 months.
This chart highlights the pull requests (in red) and the comments (in blue) as they have occurred since January 2016. Here again we see a gradual increase in contributions (trend lines added). As you would expect the amount of discussion surrounding code contributions increases over time and there is a gradual increase in the number of pull requests submitted as well. Peaks typically correspond with the various release dates of the Mautic code.
Code Comment Growth
The next chart demonstrates a comparison between comments on code between last year and this year (again keeping in mind that this year we are not showing data from the month of December).
I share this chart because it signifies the engagement aspect from the community. Again, comments and involvement increases around release times as you would expect, but the overall trend line demonstrates increased discussion occurring around the code over time.
Of course all of these charts above are specifically related to the pull requests submitted and as a result there is a significant portion of the contributor engagement that is not represented by these charts. The reason for this lies in the feature request section of GitHub. Feature requests are ideas generated by the community for future consideration within Mautic. Because they are not associated with a specific pull request they do not show in the above stats.
Current Code Status
Let’s now take a look at our current GitHub status and repositories and draw some conclusions about where we have come and where we are going to go from here. This is also a chance to identify ways we need to improve processes and new areas of focus for 2018.
Currently in GitHub there are 726 issues and 103 pull requests. Breaking the issues down further we have the following stats:
- 321 issues marked as Bugs
- 308 issues marked as Feature Requests
- 171 issues marked as Backlog
- 98 issues not labeled
- 20 issues marked as Pending Feedback
There are several conclusions we can draw from this. First, because we use GitHub for our bugs and feature tracking there is a slight skewing of perception when viewing the open issues on Mautic. Instead of there being almost 730 “bugs” in Mautic code, it is better to view this list with the appropriate filter applied. When you do this you’ll find that the relationship of bugs to pull requests is much closer to a reasonable ratio with 1 pull request existing for every 3 bugs.
The second item that is a problem for Mautic is the 98 issues that are currently unlabeled. This means someone has written up an issue but it has not been reviewed by anyone with appropriate permissions for applying a label. This is a problem. There are two possible explanations. Either we don’t have enough active community members monitoring the GitHub repositories to mark new issues with the appropriate labels or we don’t have enough community members with the knowledge to apply the appropriate labels and therefore they don’t add them.
Side Note: There’s also the problem presented by GitHub repositories and permissions that allow or disallow access to label creation and application of those labels. This is something Mautic has not yet solved successfully.
In the future we need to educate community members on reading and assigning labels to issues so that they can be correctly categorize as they are created. We also need to determine the number of community volunteers actively monitoring GitHub repositories. One of the first ways we can determine this number is by looking at the number of reviewers we saw in the charts earlier. This number gives a suitable estimates of those contributors capable of responding to issues and therefore also capable of attaching labels to issues.
There are several advantages to correctly categorizing issues. With proper categorization we can more readily identify which bugs need to be resolved first and which are feature requests instead of actual bugs. This will increase productivity from the developers writing pull requests as well as clarify public understanding of the project’s status.
Lastly, from the list of issue stats we can see that there are a significant amount of feature requests. We can draw a conclusion or two from this metric as well. Feature requests can mean the software is not completely fulfilling everyone’s ideal marketing solution (though this is a more delicate issue as Mautic should never attempt to be all things for all people). More importantly the relationship between number of feature requests submitted and number of pull requests submitted suggests that the community is made up of more end-users (marketers) or implementer types of users rather than coders or developers. In fact, when we take this ratio and compare it to the downloads from Mautic.org of the software we find a fairly similar breakdown of user types. This means the assumption we draw from the feature request submissions is accurate.
Understanding the make-up of our community when it comes to the Mautic code helps us to continue making improvements and growing. I hope that as you have read through this you’ve been able to get a better understanding of how I look at things and what the different metrics you might see or hear actually mean. Once we have a shared understanding of how to look at the Mautic codebase we will have a greater opportunity for moving faster.
August 2, 2016
The Importance of the Last Mile
Everyone talks about going the extra mile. But there’s actually something to consider before thinking about going the extra mile. In fact there’s something directly before the extra mile. And that is the last mile. Even from an early age I had the concept of finishing drilled into my brain.
Many of you who know me may not think of me as necessarily athletic. In fact you would probably assume I was your typical computer nerd with glasses during high school and you are mostly correct. I was a computer nerd and I did wear glasses but I also played sports and enjoyed participating in both soccer and basketball during my high school years. This environment helped me mature in team activities and also in other areas of my thinking as well.
As I mentioned one of those concepts has been permanently impressed on my life and affects nearly every aspect of my daily life. I hinted at it above but let me give you a little more detail about why the concept of finishing sticks with me so thoroughly.
It was a hot summer afternoon and we were running sprints. Back and forth we plodded across the dead remnants of a soccer field, the lush grass long since withered and faded under the blistering unforgiving summer sun. Goal line to the box, back to the goal line, forward to the half, back to the goal line. Repeat. To his credit the coach would run with us, encouraging us, cheering us on, cracking jokes, pushing us. When finally we were allowed to collapse exhausted onto the needle-like surface of the battlefield he would remain standing. We knew he was spent, clearly he had to be, in our youthful eyes he was ancient and yet he stood. He stood because as he would go on to tell us, it’s not whether or not we played the first 80 minutes impeccably, but how we played the final 10; the last 1. Standing rather than collapsing. Finishing the game. But not merely finishing; finishing strong. That was only the first of many lessons on the value of finishing.
Every game would begin with a huddled mass of excited, adrenaline-filled fists jammed into a circle before being thrust heavenward with the battle-cry of “Finish!” More importantly ever content, regardless of victory or defeat, was ended with the same ritual. Some times the cry was painful as loss still echoed in our heads. Other times the anthem rang out embodied with every goal and winning moment of the latest success. But always, “Finish.”
The lesson taught has gone on long past those summer evenings. Gone are the game-day lights and the glory of a sports conquest. But the concept of finishing continues on. Just as my coach had always envisioned, he was doing more than teaching us to play. He was teaching us how to live.
In a world where “going the extra mile” is praised and celebrated and where going above and beyond is rewarded with accolades and commendations, we too often lose the value of finishing. There is tremendous benefit and something to be said for finishing strong. Before worrying about going above and beyond, and before thinking about the next big step you could take, focus on finishing well. Create finished products. Deliver work done excellently. There is extreme value in the last mile.
April 28, 2016
A Pyramid Scheme for Startups
Most startups traditionally all want to approach the market in a similar way. Scratching an itch. Starting with a great idea. Focusing on fixing a problem that the entrepreneur has personally experienced or seen. This is common. And certainly nothing wrong with this way for getting started. Ultimately you have to feel passionately about the problem you’re trying to solve; the pain you want to alleviate.
If you didn’t have this deep-seated desire there’s no need joy in the task you’re undertaking. But too many times (I’m learning this too as I talk with others) this is the sole foundation and focus of the business. When this personal perspective is the only focus of the startup there will be a struggle. So how does a startup grow beyond this phase? What’s the better approach to take for a successful business?
As I learned from a good friend there is a simple diagram which can be immensely helpful in creating this structure. I call it a pyramid scheme for startups. Only this pyramid scheme is highly beneficial and immensely helpful. And totally legal.
I’ll start by giving you the picture and then digging into it a bit to better explain each level and what it looks like from a couple different perspectives.
How the marketing uses the pyramid
First, we want to look at this pyramid scheme from the position of the marketer. The marketer needs to create the branding and marketing message for the organization. They have to start with the core and work out. In this role they need to take this pyramid, start at the top, and work their way outwards (or down).
A good marketer recognizes they must begin by identifying what the company is (What we are). Once they have a good handle on the “why” for the business; they align with the company goals and objectives; and then they shift their focus to be slightly more broad and begin to create the marketing message. This marketing message should point people to what the business does and funnel traffic “upstream” into the what and why statement.
We’re Different. Here’s How.
Continuing downward the marketer then begins to build on this marketing message into some of the specific ways in which the business is different from the competition. This is the differentiating aspect of the marketing message. Again, this stage is broader still in the overall marketing context and begins to include other sources, the general market space, and a broader reach.
The broadest and most generic marketing message is the bottom of the pyramid. The last part a marketer builds out and focuses on revolves around the practical application of the business/product to an audience. How the customer would use the product.
An interesting point you’ll notice as the marketer builds this pyramid from highly specific (company-focused) to very broad (audience-focused) there begins to form a number of different “channels” or as more commonly known “verticals”. This can be easily shown in the pyramid with the following minor addition.
What you’ll see is with the addition of these vertical markets the marketer continues to funnel everything upwards into a single core message and becoming more company-centric and refined.
It’s a brilliant way of thinking about the marketing message. I think it represents similar concepts to what you’ll find if you look at Simon Sinek’s presentation on Start with Why. Which incidentally is also one of my personal biggest influences. I’ve written on that topic time and again. But this is only one part of the equation.
How sales uses the pyramid
We can take this same pyramid structure and look at it through the eyes of the salesperson. If we start from a sales standpoint we have to approach the situation from the opposite direction
The reason for this is simple but let’s walk through it anyways as an exercise. First, when you’re approaching a business from a sales perspective you have to start from a common point. The best salesperson recognizes that instead of yelling about what makes the business great the best way to begin involves listening. A salesperson that listens first to a customer, understands and helps identify pain points is going to have a much easier job providing a solution that solves specific problems.
You have to listen first.
This approach of listening and identifying pain points means simply identifying how the business/product would be most effectively used by the customer (aka the bottom of the pyramid). This is a critical step. This lays the foundation for the relationship and helps the salesperson reach the broadest possible audience. Keep in mind the verticals we discussed previously. Listening to the pain points and identifying use-cases means targeting a specific vertical path from the bottom of the pyramid.
Secondly, once the customer recognizes and relates to the pain points and how they would use the solution the salesperson can continue to refine the sales message to begin to highlight key differences between the product and the competition. This is still the differentiating step, but specifically as it relates to the pain points previously identified.
Relate to your customers
The third step is the relational step. At this level in the pyramid the salesperson takes the differentiating factors and leverages those along with the pain points to relate to the customer. Here the interests of the customer need to be aligned with the solutions provided by the company. This is the “caring” level where the customer begins to see in a semi-focused manner why this particular company will uniquely be able to help them.
Finally, the last step in the sales process is where the company can share a bit more of their personal message, culture, and experience. This is where the company can open up a bit. Note, that you don’t want this to occur too early in the relationship but rather be saved until the connection has been made and the basis for a relationship formed.
I hope you find this helpful to think about as you work within your company (really any stage company can probably benefit from this). Keep these principles in mind as you build your marketing strategy and your sales strategy. Focus your time and efforts where they matter most. Of course this isn’t a perfect picture and there are ways this could be improved upon both generally and also in specific company use cases.
As I’m learning and thinking on these things I’d love to hear your thoughts and opinions. Have you found a particular pyramid or other diagram that helps identify and organize your thoughts around preparing a marketing message (sales traffic) besides the funnel. Because, yes, I’ve seen enough funnels to last a lifetime.
February 23, 2016
Global Marketing Automation
When we talk about global marketing automation and the need for a product which can meet the diverse needs of a world market one of the first priorities becomes languages. I’ve written about this before but recent news has made this a good time to revisit the topic. More often than not people tend to forget that there are other languages spoken in the world. It’s just human nature to become comfortable and focus on your local environment. This is especially noticeable in the Western world (aka the United States). But this is close-minded and a narrow focus on the task to accomplish.
Marketing automation has traditionally been one of the largest offenders of this narrow view of the world. Case in point: some of the most well-known existing marketing software companies are proud (and actually brag) on the fact they provide their software in 5 languages. Five.
Mautic is an open source marketing automation platform where the focus from the very first day has been on a global environment and the vision for a product available to everyone in every language. This community-first approach has lead to some incredible milestones being reached at insane speeds. How incredible? Let’s look at some numbers.
More than 253 collaborators have joined the Mautic translations team. Together these engaged volunteers have actively been translating Mautic into 24 languages. With more than 47 languages started. That’s amazing! (24 languages is 500% more translated than the other marketing platforms.) And the Mautic community has accomplished this in under 10 months. That’s not a typo; in less than a year this community has come together and built a robust platform available in a way unlike anything before. Local and familiar.
But this is not the end of the story. Even Mautic has a long way to go. Our community has some great momentum but this is not the time to sit back and relax. Because this is the bigger picture:
“There are roughly 6,500 spoken languages in the world today.” (Source)
And so, even though Mautic dominates the marketing landscape there are still thousands of languages yet to go. And as we have done so far we will continue to do, pressing on, empowering people around the world to use cutting edge marketing software in their native language. Because that’s what open source and community means. This is the power of our community and this is the power of Mautic.
February 9, 2016
It Only Takes One
I love talking to people and listening to them as they share their story with me. I find it fascinating to hear about what they do, what they work on, how they live, and what they love. There’s always one thing I notice when I have these conversations. When you ask someone what they do you will most often get some story about how they make money. Inevitably the question of what someone does is intrinsically tied to their bank balance. But if that’s the case then you’re asking the wrong question.
I’ve seen many posts before suggesting alternatives to the question about what someone does which will give you a better answer or a more enlightening response. I love those suggestions because that’s when something different happens. That’s the moment I notice something different.
Ask a better question, get a better answer.
Ask someone what they love, or ask someone what a perfect day might look like to them (and feel free to specify that it does not need to even be related to work) and watch the reaction and response you get. You’ll immediately see what I’m referring to. They don’t rattle off some answer related to how they pay their mortgage. No, instead you’ll see a passion ignite in their eyes, you’ll hear a lift in their voice, maybe even a smile will slowly emerge across their face. This is golden. This is why I love to listen to people share their story. I enjoy hearing what people are passionate about. I especially enjoy watching them get excited and feeling that excitement start to resonate in my own spirit. Because in this moment, in that flicker of a spark, you connect with someone on a deeper level.
Their passion, their excitement, their eagerness to share with you something they deeply care about and love is contagious. When you’re passionate about something and you share it with someone else you have the opportunity to go much further than answering the “what” question, you answer the “why” question. Did you catch that? Your motivation and energy to accomplish something which answers your “why” can resonate with others.
Imagine this with me now. What happens if you were to spend time each day sharing your passion, and your driving force with others. This contagious spark spreads. Your passion leaps from person to person, motivating, inspiring, and engaging. Those individuals in turn will share that passion and that experience with another, and another, and another. Suddenly what started as your vision, and your passion, a single solitary flame burning inside you is now a raging inferno spreading farther and faster than you ever imagined. Now you’re no longer alone, now you are a group of individuals brought together by a common goal, a common purpose and a common passion…wait, does that last sentence sound familiar? It should. I used a similar sentence once before in a previous post, only this time I’ve left off the first three words. Here is my previous sentence:
“Every successful community must be centered around a common belief, a common passion.”
You see, that same passion which excites you, and ultimately those around you; that same driving force which answers your “why” and that of others ultimately provides you with the basis of a community. And as that fire spreads your community grows.
People often ask why Mautic is such a successful community. They wonder at how we’ve grown so incredibly fast in such a short time. The answer is easy. In fact, the answer is so easy at times people struggle to believe its true. But it is. The Mauticians which make up our community have a common belief and a common passion. We rally around our goal and the answer to our “why” and we spread like a wildfire. If you still don’t believe this, talk to a Mautician, find someone who knows and loves Mautic and ask them about it. Watch the light in their eyes, the smile on their lips, and hear the excitement in their voice as they tell you how we’re revolutionizing the world, disrupting an industry, and empowering everyone. And then afterwards, well then I imagine I’ll see you very soon in the Mautic community.
Find someone who knows and loves Mautic and ask them about it. Watch the light in their eyes, the smile on their lips, and hear the excitement in their voice as they tell you how we’re revolutionizing the world, disrupting an industry, and empowering everyone.
January 12, 2016
Free Software and Success
Marketing automation is highly complex. A free app gives the wrong signal as if everyone with MA can be successful.
I recently saw this tweet and it annoyed me. The foundational belief that if something is free it cannot therefore be of real value is completely and totally false. Availability has never implied success. Cost does not unequivocally equal value. Granted there are many areas of life and the world where a brand may charge a premium for a similar product. You may find yourself paying for a logo, or a particular “name brand” recognition, but this hardly means the higher the price the greater the value.
The reverse is even more fallacious. The more affordable (or even free) price does not automatically relate to the quality of the product, the value of the software, or even the ability of this software to be helpful in future success.
A free app means the availability of the raw goods, the resources, are available without cost. The impetus still lies within the business to correctly implement the software to be successful. Let’s take a different perspective.
Imagine you find a stunning piece of software, it’s beautiful, it’s highly functional, it does absolutely amazing things. But you can’t find the price anywhere. You’re convinced this software is just what you need so you agree to begin using it regardless of the price. Now, you have two possible outcomes, you either fail to successfully implement the software and it sits there, beautiful, shiny, untouched. Or, the second option, you take this software run with it, implement it, and it makes your business incredibly successful. You’ll notice one thing that’s not revealed. The cost. Through this example what we discover is that the price of the software plays absolutely no role in the eventual outcome.
The price of software tools used should never be thought of as an indicator of the business’s eventually success.
Now, marketing automation has traditionally be considered complex, detailed, and difficult to use. But the status quo exists to be broken. Disruptive organizations, like Mautic, demonstrate this fact. Mautic revolutionizes the marketing automation industry with convenient, easy-to-use, intuitive marketing software. Mautic empowers everyone, and gives each the tools they need to be successful. Mautic gives the raw product. Mautic supplies the things necessary to be a success; but does not guarantee it. And an interesting fact, as we look at Mautic and what it has the capabilities to do, we haven’t once discussed price.
This leads to two obvious and glaring contradictions to the initial suggestion. First, marketing automation is no longer complex and difficult to setup or use. Second, Mautic doesn’t make you successful any more than having the various parts to a bicycle means you can ride one. Regardless of price, software is a tool to be used to accomplish a goal. You can read more about this theory in a recent marketing automation tool article on Mautic.org.
Bottom line: Don’t reject something new based on preconceived possibly erroneous notions.
November 30, 2015
The Importance of Marketing Tech
Recently I answered a question on Quora about the efficacy and “rule of thumb” for the benefits of marketing technology and how this tech should increase revenues. I thought it was a great question and followed a train of thought I have recently been pursuing so I added my answer to the page.
I believe you will be hard-pressed to find any definitive metrics for how efficacious marketing technology is for a business. The reason for this is in part related to a previous blog post I wrote on Mautic.org. The short version, summary, of that post in essence says that marketing automation platforms and other marketing technologies should always be considered tools to be used and not solutions. Here is what I mean and how it relates to this question. Let me use an analogy to make it easier to understand.
I’m very interested in bass guitars. I love the idea of laying the foundation of a musical rhythm the rest of the band then builds upon to create beautiful music. Bass guitars come in a variety of sizes, shapes, and styles. Each has their own beauty and their own purpose. They are powerful tools that, when placed in the right hands, can be used to impress and stun the audience. But, if I were to give a bass guitar to my son (awesome kindergarten kid) the result would be vastly different. Obviously you naturally and instinctively understand this difference. The guitar didn’t change-the player did. And the results are completely different.
The analogy should be fairly self-explanatory. Those same principles apply to marketing tech. These are tools to be used and with the right marketing department they can impress and stun the C-Suite and others. Inexperienced or new marketers will find the benefits far fewer and their path much different.
Once we’ve established this baseline understanding there are numerous metrics and statistics which demonstrate what is possible with effective marketing strategies. But remember, you should think of this like putting a Rickenbacker 4001 in the hands of Cliff Burton. If I were to pick up the same instrument my results would be different. Here are a few statistics floating around regarding marketing technology and improvements in efficiency and costs. Your results may vary.
Marketers who implement marketing automation see 53% higher conversion rates and annual revenue growth 3.1% higher than others.
Email marketing has an ROI as high as 4,300%.
Successful lead nurturing programs average 20% increase in sales opportunities.
So, there’s three quick stats, a quick google search will yield hundreds more. The key here again, is that the marketing automation platform, or the marketing technology used is only the tool to help you be a better marketer. The right tool can save you hundreds of hours. Pair your expertise with a powerful platform and the results will be epic.
*For full disclosure, I contribute to the Mautic, free marketing automation platform, and have a strong bias to the belief that a powerful platform doesn’t have to cost a fortune. Mautic is an open source tool capable of helping you rock out like Metallica.
June 4, 2015
I know you’re probably thinking when you read the title that I’m referring to socially unacceptable or perhaps profane talk. That’s quite far from what I’d like to share with you though. I’m referring to the differences of languages around the globe and the impact that these languages have on communication, growth, and community.
As most of you know I am deeply involved in the Mautic community. This isn’t the first community I’ve been a part of and I doubt it will be the last, but Mautic does hold a special place in my heart. Recently I witnessed something that gave me chills of excitement. You know what I mean, those raised goosebumps on your arms that tell you something big is happening, something way bigger than yourself and something so exciting your body reacts physically to its revelation.
You may be wondering what triggered this response. Language. Specifically the wonderful, beautiful Thai language. Not too long after the Mautic community was formed and began to grow I received a contact request from Akarawuth Tamrareang. He was very polite, very friendly, and very excited. He was excited because he saw an opportunity. He saw a young, vibrant and growing community that could be thrust forward to an entirely new level as a result of his direct influence and skills. He reached out for confirmation and support in his effort. His undertaking would not be a simple one. Krit, as he is affectionately called, wanted to translate the entire Mautic website into Thai.
I have to pause here and give you just a bit more personal information. I am an American, more specifically, from the United States. I took the required foreign language courses during my educational years but sadly I am no proficient in any language beyond English. (Unless, as I like to joke, you count code as a language and then I know a couple more). I travel extensively around the world and it never ceases to amaze me how many people speak multiple languages. I admit I am always left in awe at their ability. I respect and appreciate the skill this requires and the dedication of so many to be able to communicate in multiple languages. Now you know just how incredible I find Krit’s request and his ability.
Of course the Mautic community encouraged and supported Krit in his task and recently I was excited to reveal https://th.mautic.org as a translated version of Mautic.org. This is what gave me those chills. This is incredible. Almost overnight the Mautic community has been expanded in a mighty way. Now every native Thai speaker can experience and learn the power of Mautic in their own language.
This is the kind of thing that grows a community. It starts with one. Mautic is blessed to have Krit. But this is just the beginning. And I am excited to share that there are others following already! I will share each with you as they are announced!
And if you read Thai (and even if you don’t) you should take a look at this beautiful site.
March 18, 2015
The Power of Product Hunt
Chirp. That’s how it began. A single, simple, chirp from my Tweetdeck. I was in the middle of a meeting in my office when the tweet came in and I glanced only half-interested while deep in conversation. When I read the tweet however everything else stopped.
— Product Hunt (@ProductHunt) March 17, 2015
That was all it said. Added as a maker of Mautic. (Our open source marketing automation platform and community.) But I knew what this meant. I was very familiar with the twitter handle @ProductHunt. For those that don’t know what Product Hunt is here is a brief explanation. Product Hunt features a list of the best new products on the web. Every day the list is restarted. Throughout the day these items are voted on by the community and comments added. This social aspect allows trending of the most popular new items. For startups and early stage communities this is an incredible achievement and I was well aware of the power of Product Hunt. I’d even submitted Mautic in the past but had never heard anything back.
Happy St.Patrick’s Day
Now, here on St. Patrick’s Day, I had just received notice that we’d been added. Things kicked into high gear almost immediately. I excused myself from the meeting I was in and quickly informed the rest of the Mautic community that we had been “hunted” as Product Hunt refers to the adding of a new item.
And as expected, traffic spiked. (See graph above) We watched – anxiously monitoring our web servers as they creaked under the sudden load increase. But though we may have been anxious we had a confidence because we had some great tools in place.
Some Of Our Tools
We were using a CDN for static assets (CloudFlare is amazing), we also have a secret weapon (not too secret). We use New Relic. We could monitor throughput, response times, CPU usage, memory usage, and errors in live time. This was incredibly helpful as there were moment when we were registering a dozen accounts a minute and we found a problem with simultaneous registrations. We were able to fix them incredibly quickly and notify those few affected users directly. Remember, first impressions are everything! Zendesk was also a great help in monitoring and responding to any specific questions or support issues.
Of course we had thoroughly tested and re-tested to ensure we could handle a traffic increase and traffic spikes (we knew we would be wildly popular once people began to hear about Mautic). But there’s nothing like the confidence that when things are actually exploding you are capable of dealing with the situations as they occur.
Helping Continue Momentum
We continued the buzz by promoting Mautic’s addition to the list through various social media posts. We had to work fast because although we were aware of Product Hunt and hoped to be featured we had to create the resources on-the-fly. We created a custom short URL, http://mau.tc/prod-hunt which would be easy to share (Thanks to Bitly.) And then very soon after the announcement we released this on our social media platforms:
But we didn’t stop there. We continued to share the good news to hopefully increase the visibility of our listing throughout the day. We updated all our social media platforms at the same time. Following some good advice we didn’t stagger our announcements but posted everywhere.
Later we created a second social media announcement focused on the specialness of being listed on St. Patrick’s Day and later in the afternoon we released this graphic:
The response was tremendous. These social media posts helped to boost our presence and awareness of our placement on Product Hunt. As a result we saw an increase in upvotes on the site and our listing began to trend. Things continued to grow as a result and now, the day after we are still “above the fold” as we continue to trend into the second day on Product Hunt.
All in all the day was a thrilling and somewhat wild ride. We saw thousands and thousands of new users and an incredible response to Mautic. Just as we had all suspected, people are thrilled when they discover the power of free and open source marketing automation. My alert may have started with a single chirp from a single tweet, but it wasn’t long before the notifications were coming in so close together the sounds were overlapping.
If you have a startup or a young community then you may be aware of Product Hunt already. If not, you should be. If you are, take a look at some of the tips I shared above to help you capitalize on your listing and do everything you can to maximize your social sharing!
February 23, 2015
Scaling Applications for Global Communities
Below is a transcript of the talk I gave recently in Oman at their Free and Open Source Software Conference (2015). If you want to watch the talk instead you can do so on YouTube starting at the 1:18:44 mark (Here is a direct link to my talk on scaling applications for global communities). Or if you prefer to download and read later, here’s a PDF version.
1. The Personal (about me)
I know you probably aren’t too terribly interested in hearing my entire life story so I’ll keep this short and sweet. As you may have seen, or read in your pamphlet, I am deeply involved in open source and several different projects. I spend an incredible amount of my time both creating code (I love to write code) and also telling others about open source code. I truly love speaking about open source and sharing the power of those communities with others.
Let me give you just a little bit more information about what I work on. I am extremely proud to share that I am the founder of an open source community for marketing automation, called Mautic. But I contribute to a number of other projects also. And one of those roles, in fact, the very first open source project I ever had the privilege of working in was Joomla, an open source content management system. I started my journey in Joomla just as a user and a developer (remember, I love to write code). But over time I became more involved with the community until today. Now I’m the community development manager for the project and am a frequent speaker, project evangelist for Joomla.
2. The Project (about Joomla)
This is without a doubt an incredible community. Joomla has been around since 2005. Fittingly enough Joomla and I share a birthday, August 17. Many of you probably know that Joomla was a fork from a previous open source project called Mambo. Since 2005 Joomla has continued to grow and expand and is now recognized as the second largest, and most downloaded CMS in the world. That’s pretty big news. It gets even more exciting. Joomla not only holds the second largest CMS market share but is the largest not for profit, community-driven CMS project. No other CMS platform has this type of honor.
So that’s a pretty nice introduction to Joomla, but maybe a few more specific examples will help to put the true size of the Joomla project into perspective. And you’ll see later how this all ties in together.
- Joomla is multi-lingual
- Joomla is accessible
- Joomla is convenient
Great ideas? Well Joomla is much more than just a few impressive statistics. The Joomla community focuses on an aspect much more important than just the lines of code. Something deeper. Joomla focuses on people. The individuals who make up the Joomla community. These unique and special people all play a vital role in the success of the project. Here are some numbers related to the growth of the Joomla community.
- Joomla has been downloaded over 60 million times
- Joomla has more than 2,000 forum posts every day
- Joomla has more language translations than any other CMS
Again these are some fine examples of the size and scale of the Joomla community. This also demonstrates the growth rate for the community. I mentioned that Joomla focuses on people. I want to return to that in a second. But before I do that I want to touch briefly on just a couple more areas related to the Joomla project.
These two areas are often the most difficult to bring up when sharing Joomla with others. It’s not always pretty. And it’s not always easy. But the truth is Joomla is just like any other community and any other project. It has struggles, it has problems, and it ultimately has successes. Let’s take a minute and look more closely at a few of the struggles which face the Joomla community. Perhaps you can relate to some of these.
Joomla has grown quickly and has struggled to maintain order. Obviously anytime you see the type of amazing growth that the Joomla community has seen you will have difficulty maintaining order and avoiding chaos. It’s almost inevitable you will find yourself struggling with keeping that easy-to-understand, easy-to-get-involved nature you often find in smaller communities. When projects scale to huge sizes the simple act of getting involved as a new volunteer can be an incredibly difficult task (and sometimes an impossible one). This struggle for order is even more of a potential failure when the project is completely and totally community driven. Without any single entity supporting the community, helping to make the tough decisions, and ultimately ensuring the project’s forward progress it can become difficult to avoid confusion and chaos. I’m not saying it’s impossible, Joomla has worked very hard to show that this is a possibility. What I am saying is that it can be difficult and it’s certainly a struggle.
Joomla has struggled with adapting to change. Just as you will find in many large and established companies (Think Microsoft). It can be a very difficult struggle to stay relevant and ensure your project doesn’t begin to just tread water. The minute you begin treading water is the minute you begin sinking. A project must maintain its vision for the future. A community must be driven to continue improving, innovating, adapting to change around it. When a community (or business) does not allow for change, it will ultimately die. If we consider Microsoft as an example then we can all relate to this sense of stagnation. What was once a booming technology company on the cutting edge of everything is now a behemoth trudging, plodding along through the daily chores of bug fixes and patch Tuesdays. Gone are the glory days of new release after new release. They spend millions (maybe even billions) of dollars in their research and development departments. They understand the power of innovation and the need to return to those monumental discoveries. Joomla must also be able to pivot, to make changes, to improve and adapt.
Those are a couple of the struggles the Joomla project faces. They are difficult to share but understanding and knowing your struggles is the first step in overcoming them. So I talk about them openly. I share them with you and I hope to share how we overcame them. It’s an ongoing, continual state of learning.
3. The People (about the community)
I mentioned the Joomla community and the focus that Joomla has on the individual volunteers, contributors, and people which make up the Joomla community. Let’s look now in a bit more depth at several facets of these individuals. This is the good stuff. If you only take one thing away from my talk today. Learn this. People matter. More than code, more than working groups, more than teams, more than documentation, more than anything – the people who are giving their time, who are giving their lives to the project: these people matter. That’s one of the most important things I’d like to share with you today. Relationships are important.
Let me tell you a little story. A Joomla story. This is the story of a person who is relatively quiet and shy, would never step outside their comfort zone and would never think about standing in front of a group of people to talk. In the beginning it started with a few small bug fixes. A pull request for improving a module. Nothing fantastic and certainly nothing ground breaking. In fact I’d dare to call them worthless fixes. But they weren’t worthless. Because they served as the beginning for something greater. These seemingly minor one or two line comment spelling corrections were just enough for this individual to stay committed to the project and continue keeping involved in the community. As time passed the encouragement from others in the community helped this person become more involved. Soon, at the bidding of his new friends within the Joomla community this individual applied for a leadership role. He was welcomed with open arms and continued his involvement soon he was spending a significant amount of his time each day devoted to the success of Joomla. He became more and more involved and was passionately committed to the community. All of this came from a few almost meaningless lines of code. Why? Because of the encouragement and support of others in the community. As you have probably guessed this is my Joomla story. This is how I came to my position in Joomla. If you hear nothing else from my story I hope you will hear this: Encouragement, support, and the relationships formed with others in the community are of utmost importance.
If we are to explore the complexities of scaling an application for a global user community then this should be our one guiding principle: People matter.
There are of course many aspects which can prove to be difficult when growing an application to global size. We will discuss a few of those and look at how Joomla has handled each. I refer to Joomla as our case study because as I have demonstrated above Joomla is a worthy and fitting case study for us to examine.
Let’s look at three different problems which must be overcome if you want to scale your community globally. First, languages can prove to be challenging. As you are aware even from my speaking here today there are times when languages can prove a difficult obstacle to overcome. As your community or application grows beyond the boundaries of your country or your specific language it will inevitably face this problem. Each new language, each new country where your application begins to be used introduces a new set for potential problems. Let me explain. When I say languages are a difficulty I am not referring merely to the words. Of course the words present the most obvious challenge, but in the world we live in today we are blessed to be able to translate our words.
Notice, I said translate our words because translating our words is not the same as translating their meaning. This is where the true problem lies. There are so many other aspects of language which must be considered. Things such as tone of voice, implied meaning, cultural differences, are just a few ways in which language barriers can prevent successful project growth. In order for your project to be a success you must consider all of these aspects. Take Joomla for example. Joomla has been incredibly successful in this regard. If you’re not aware let me share a statistic or two with you. The Joomla CMS currently has 58 different translations that’s a staggering number of languages. Each of those translations has a working group of individuals dedicated to keeping that language up-to-date with each new release of the software. But as I mentioned it’s more than just language strings or words. Joomla works very hard to ensure that implied meanings and cultural differences are also considered when working groups and individuals collaborate. Great care is taken to be considerate in all communications. This sounds trivial but is instrumental to the overall success of the project. Joomla has created a wonderful culture code document which outlines specifics for how the Joomla culture should be created and maintained. Languages are more than words.
I offer a second example from a much younger and newer community, Mautic. I have begun implementing exactly what I stand before you and share. Languages are an important pillar in the building of a global community. Within only 3 weeks of launching the beta for the Mautic open source product we have been able to see 5 complete language translations and a dozen more started. It’s exciting to witness and it shows to everyone that the Mautic community values each language and each country.
Here is your first lesson: If you want your application to be globally accepted, to scale to the size of a world-wide audience then you must consider the value of languages, both in word and in meaning.
Next we turn our attention to a second important problem that must be overcome when scaling globally. Timezones. It is often easy to forget in a daily routine of application development and product releases that there is an entire world of varying timezones. 2PM in one location is 2AM in another. I can tell you first hand speaking from my own experience in the United States it can sometimes be forgotten that not everyone is on the same relative time as I am. If you are interested in being able to grow your community, or your project, or your organization to a global size then you must remember and account for varying timezones. Let’s take another look at Joomla and how this community handles the timezone problem.
The Joomla leadership is comprised of three different teams working in harmony across the many aspects of the project. These teams are each consisting of individuals from around the world. Each team has dozens of different timezones. Joomla has used several different tactics but one in particular has proven to be useful and serve the community well. Joomla alternates the the schedule of leadership meetings. What does this look like? Joomla changes the meeting time when a leadership gathering is held. By doing so Joomla ensures that there is an equal opportunity for each person to meet in a timezone that is most convenient for them. (and everyone shares the same inconvenience) The timezone is an often overlooked important aspect of being able to scale an organization.
In the beginning this can be a difficult task. When your community is small this will be a challenge and will require dedication and attention. I share an example from Mautic. This community as I told you before is much younger and much smaller. As a result the initial community members must be more flexible and more dedicated with their time. When beginning to grow your community be prepared to spend significant amounts of time at all times of day and night. You may not sleep much! But if you are committed to seeing your community be successful you must be prepared to make the sacrifice.
The second lesson to learn: In order to increase the global availability of your community and project you should pay attention to the timezones of your contributors and volunteers. Make your community convenient.
We arrive now at our final problem you should seek to overcome as you grow a global product. I say final, but in reality there are many more problems you will face. The task of building and scaling an application is a constant and ongoing challenge. But we look in particular at three problems and this final one is related to accessibility. Just as you want your meetings (timezones) and your communication (languages) to be convenient you want also for your community to be accessible.
I’m quite pleased to share the success Joomla has seen related to being an accessible project. Don’t mistake me. One of the reasons why Joomla has been successful in regards to accessibility lies in the fact that it continues to focus on and constantly improve accessibility. This is not a one-time thing to be solved and then ignored. This is a key point. Joomla continues to focus on this aspect of its community and the software. Through the use of specialized formats, screen reader improvements, and special administrator templates designed specifically to be accessible Joomla shows its incredible attention to accessibility.
Here is the third lesson: To scale a global community requires focusing on every type of user and being a community whose people and whose code is accessible to everyone.
So we have covered three lessons to help scale an application for a global community. Dealing with languages, timezones, and accessibility. As your project and community grows you must focus on each of these areas if you want to overcome the complexities of a global community.
Let me quickly give you some practical steps for implementation. First, you must plan ahead. Don’t think only about what your code or your community looks like today. Look ahead at what it will become in the future. Plan for what will come in future days, weeks, months, or even years. Be prepared and be constantly ready to make changes when needed. Next, monitor everything. You will need to be vigilant as you watch your community grow. You must be monitoring your code to ensure it remains stable and can handle an increased load of traffic. You must be monitoring your community to ensure it continues to grow and that it is accessible, and convenient for new contributors to take part. Lastly you should take what you have planned, mix with what you have seen through your monitoring, and apply it to improving your community. You cannot simply observe and make plans without implementing them. You must be looking to constantly improve. Your code must adapt and grow as new opportunities arise. Your community must adapt and grow as you scale to larger size.
Let me close with this. There is no formula that guarantees you will be successful in scaling an application for a global community. It simply cannot be put into a specific step-by-step exact plan. Rather what I offer here are some important lessons that when put into practice will offer a strong path to lead towards a successful global project. I want to thank you again for this opportunity to share with you what Joomla has proven to be a successful strategy for scaling and what Mautic is also following in like manner. And I wish you each success as you seek to grow your communities and projects. If you have other questions or ideas feel free to reach out to me. I would be happy to answer any questions that I can and look forward to hearing what you are passionate about!
February 4, 2015