June 13, 2018
Apples, Oranges, and Communities
“You’re only focused on the developers.” The comment stung but only for a second. I was deep in conversation with a few Mauticians when this supposed truth bomb was dropped in my lap. But rather than devastating me, or causing me to explode in a defensive nature, I let the comment soak in. I rolled it over in my head and attempted to evaluate the truthiness of the words. Here are the conclusions I came to as a result.
What am I focusing on?
I appreciated this reminder about how vitally important it is to focus on the many different type of community member. In other words, not everyone is a developer. I’ve been working in communities and developing communities for the better part of the last decade. And still, still I struggle with remembering this valuable fact.
I’m an engineer at heart. I love creating beautiful code and I love creating process. I love the ability to create order from chaos. Or create functionality from nothing. In addition to just the code I am hyper-focused on the presentation. I’ve written about the topic of UI/UX frequently on my blog (Most recently I wrote about the concept of UX writing). So, code + design are always the first and foremost on my mind.
I’m sharing things about myself in order for you to have a better understanding of what comes naturally simply by default for me. In this situation these are the things which influence my responses and my “top-of-mind” areas of focus when considering community and community growth. I would suspect you are each similar to me as well, albeit with different focus items.
This is the reason why the comment which turned it into a conversation was so important to me. The statement made me look inward and evaluate how I was doing as a Mautic community leader and how the Mautic community was growing. Were there areas in our community being neglected? Were we as a community overlooking valuable contributors and passionate volunteers simply because they didn’t look like everyone else?
And all of that brings me to my somewhat unusual blog post title. I always hesitate to share common idioms in an effort to not bore you with something I assume you already know. However I’ve found there are usually one or two who appreciate the quick response of something they remember only vaguely.
Why are we talking about fruit?
The phrase I refer to in my title says, “Like comparing apples and oranges.” This classic phrase is usually called upon when someone is attempting to compare two items which are clearly different. The point being that the person making this comparison is neglecting or overlooking the rather obvious fact that at the most basest of levels the two items are simply incomparable.
And of course the final item in the title refers to our communities we live and work in. Comparing community members or making the base assumption that every community member looks the same (aka has the same skills and talents and focus) is just as flawed as fruit comparisons.
How does a community grow?
When we reevaluate our thinking about our community and we look with a fresh focus on the diversity found in skills, talents, and abilities we see something more than differences – we see strengths.
These strengths, these unique qualities, when they are recognized and encouraged, result in community growth. And this little secret is what everyone is seeking in community growth hacking. A community typically forms around a common set of shared values (Seth Godin’s Tribe mentality). When we recognize this foundation then we can turn our focus to our differences.
Reference: Tribes and the reality of the worldview.
Why are differences so important?
The previous paragraph leads me to ask this next question. Do differences actually make us stronger and help us grow faster? Isn’t the opposite view, of a unified approach, better and more productive? The seeming contradiction however ignores the fact of a strong shared foundation of values. There is a basis of unified beliefs and a shared vision (this is the why of the community). The differences are the unique additional qualities of each person. And here’s the reason it matters, wrapped up in a biblical expression:
“If our bodies were only an eye, we couldn’t hear a thing. And if they were only an ear, we couldn’t smell a thing.”
— 1 Corinthians 12:17 (CEV)
Simply put, if everyone is the same (an eye) in a community (body) then there are all sorts of things (the act of smelling) which cannot be done. In other words, we lose out on incredible and valuable functionality. This implies therefore the inverse is an increase in functionality. Our differences make us stronger.
Mautic celebrates differences
The conclusion of my short mental journey down this path was a realization of two facts. First, Mautic is an incredibly diverse and unique community. We share a common set of beliefs and goals, but beyond that we each have unique talents and abilities. Mautic as a community embraces those differences. Second, while I was reassured after this mental exercise I was not neglecting any particular subset of our outstanding community, I was thankful for the opportunity to review my actions and motives.
If I could leave you with a word of encouragement as you are in a community (or possibly building a community) – consider your differences. Seek to support, encourage, and empower volunteers by highlighting their strengths. Do this and I guarantee you – you’ll be amazed at how easy it is to hack your community growth.
June 6, 2018
Recently I posted on Twitter a personal observation about growing older and learning to appreciate the value of disagreement and even of a heated discussion. Maybe I’m growing up or maybe I’m just getting older, regardless, I’m beginning to understand (I’m a slow learner) it’s not always a negative, desperate situation when there’s a conflict. Not every conflict has to be immediately resolved and there doesn’t have to be the notion of a singular solution. I’ve written before about the ability to hold opposing views in one’s mind and maintain relationships. This lead me down a course of thought based on an adumbrative conversation I found myself engaged in with a close friend in the Mautic community.
A conversation with something missing
In this chat there wasn’t so much a significant difference of opinions indicative of a more systemic problem; rather we were exchanging differing views of a situation and each attempting to persuade the other to recognize our rightness. Halfway through this verbal volley I was struck with a realization. My deepest problem. The one thing keeping me from being able to accept or deny the veracity of his points was what I believed to be the lack of facts. What I needed was the logic, the reasoning, the facts behind the opinion being expressed.
Aside: To be clear, I didn’t believe simply knowing the facts would immediately invoke my unwavering agreement and/or support for his statements. Those conclusions would remain to be drawn.
The idea behind fact-based feelings
I know it sounds a bit odd initially to suggest something so strange as fact-based feelings and the meaning may be obtuse at first, but here is my thinking behind such a statement: Opposing views are not the problem, nor are differences of opinions; but without a valid foundation of factual information it becomes very difficult for those feelings to be appropriately conveyed.
Returning to the conversation I was in the midst of I realized what I was attempting to extract as we continued were the facts which were causing the feelings. And I believe this same problem exists in many other interactions as well. There becomes an increasing importance to have at least some basis level of fact for what you believe.
Debating without facts
Whenever there is a lack of facts in an argument and you’re working completely and solely from the premise of feelings it becomes increasingly difficult to not only convince someone of your viewpoint but to even get them to listen with an open mind. Facts are the crucial foundation upon which your feelings can be based and subsequently your point made.
Based on this understanding, even if those facts may lead you to a drastically different outcome from someone else who hears those same facts, the simple act of fact-based debate lends credibility to your argument and opinion. This also gives you a tacit basis you can support and defend (passionately and with feeling).
Yanni vs Laurel anyone?
Admit it, the title caught your eye right? In case you missed it, a viral internet meme captured the attention of everyone with a simple audio recording of a distorted voice saying a name. The results were fascinatingly bisected. And the twitter “wars” raged on. Staunch supporters for both names were adamant in their belief the voice was saying only the name they heard. Here’s the original, offending tweet question which started the craziness:
What do you hear?! Yanny or Laurel pic.twitter.com/jvHhCbMc8I
— Cloe Feldman (@CloeCouture) May 15, 2018
This is a perfect example where a fact-based argument lends credence to a viewpoint even when the resulting interpretations are polar opposites! The reason I say this with such confidence is due to an effect known as Bistable Audio. Bistable audio can be perceived in two separate ways. In essence this is an auditory illusion. Here’s another example:
Listen to the audio file above. Do you experience a switch in the tune?
— Media Licence: Music vector created by Freepik
Bistable stimuli can be perceived in two separate ways. The sound you hear can be heard in two ways: as triplets of an A-B-A pattern or as two simultaneous streams of an A-A-A-A pattern and a B-B-B-B pattern. Come on, that’s just cool right?!
Now let’s return to the Yanni vs Laurel auditory anomaly. As it turns out, there’s a physical (and factual) explanation for this phenomena! Based on your age and hearing acuity you will actually be able to hear different frequencies. This quality of this particular meme was so distorted it lent itself to multiple frequency distributions of audio and as a result a different outcome based on the individual’s sense of hearing. (Fact-based!)
I find this to be a particularly fun and light-hearted (even slightly-humorous) example to the premise of this post; because both sides are arguing with feeling … but both are based on fact!
The elephant in the room
I’ll leave you with one final anecdotal example. Many are probably quite familiar with this age-old parable. In fact, it’s become so common as to have it’s own Wikipedia page.
A group of blind men heard that a strange animal, called an elephant, had been brought to the town, but none of them were aware of its shape and form. Out of curiosity, they said: “We must inspect and know it by touch, of which we are capable.” So, they sought it out, and when they found it they groped about it. The first person, whose hand landed on the trunk, said, “This being is like a thick snake.” For another one whose hand reached its ear, it seemed like a kind of fan. As for another person, whose hand was upon its leg, said the elephant is a pillar like a tree-trunk. The blind man who placed his hand upon its side said, “Elephant is a wall.” `Another who felt its tail, described it as a rope. The last felt its tusk, stating the elephant is that which is hard, smooth and like a spear.
Each of these men perceived the truth differently and as a result based their feelings and subsequent argument on their “version” of the truth. They were all right…and all wrong at the same time. But the basis of fact allowed them to argue passionately each from their own point of view.
Base your debates (and feelings) on fact.
Conflict is inevitable. Humans have the essential ability to reason and draw conclusions. Based in facts and encompassed with feelings they postulate and theorize their worldview to others, engaging in debate, attempting to persuade, coax, and entice those opposed to concede their view. In all of this, the basal element is fact. Without this fundamental foundation the arguments will be meaningless and nothing more than a benign insignificant waste of time and emotion.
June 5, 2018
The Power of Passionate People
Stop for a second. I could almost bet money that you read this title and instantly thought about open source communities. Of course it’s entirely possible that inclination towards open source is entirely my own due to my deep and enduring focus on building lasting communities and the power of open source. But I have to believe that within all of us there is a notion that passionate people belong in communities. We naturally associate the outpouring of passionate work with volunteers. But as I asked at the outset of this post — I’d like you to stop and think more about this.
The composition of a passionate person
Let’s start by exploring what the make-up of a passionate person actually looks like. We are I am sure all familiar with the rather standard top three dictionary definitions of passion; but if we look down the list a little further we’ll see other common definitions. One in particular stands out to me:
passion [pash-uh n]: (6) A strong or extravagant fondness, enthusiasm, or desire for anything. — Dictionary.com
So our standard notion of passion needs to be expanded for our everyday understanding and usage. In practice then a passionate person is one who exhibits strong enthusiasm for something. This is the idea we are taking into consideration today when discussing the composition of a passionate person. Someone who is crazy over accomplishing their mission. A person seen as extravagant and maniacally focused for their impassioned actions.
But there’s something else that’s relevant when discussing the constitution of a person exhibiting extraordinary zeal for a subject. An individual may demonstrate this level of fervor in one area of their life while trudging through the mundane daily rituals of a dozen others. In essence what I am suggesting then is an individual can be both passionate and dispassionate, depending on their environment and any particular facet of their life. There is no overarching global “passionate” status whereby people are measured.
Passion therefore is not contingent solely on the person but also on the particular aspect being evaluated with the person. The responsibility for passionate behavior lies not only with the person but also within the object eliciting the passion. (whew, that was deep!)
Power exists within everyone
Every person contains some element of power within them. This power takes on a variety of forms and is exhibited in a variety of ways depending on circumstances and settings. Power in the sense of energy, strength, mental efficacy, etc… We all have a propensity for exhibiting strength and we seek out ways to showcase or prove our power. As humans we have an instinctive desire to find outlets by which this (and by extension ourselves) can be validated.
Applying these principles
Now if we take these concepts and put them into practice what we find is a rather natural conclusion. When a person is empowered they exhibit greater passion. Their built-in desires have been fulfilled and this causes feelings of excitement and enthusiasm (aka passion). In this way then we can see a virtuous circle begin to form. The more empowerment felt, the greater the excitement.
As you can see from the previous paragraph this lends itself first and foremost to communities. In these circumstances individuals are able to be promoted purely based on a concept of meritocracy. This isn’t of course as easily reconciled in standard business environments. This is due in part to the injection of monetary reward (every job pays a salary) and the instant that some fiat currency is introduced into the equation the predilection is completely shifted off of empowerment and passion. But perhaps this shouldn’t be assumed so quickly.
Starting with why
If you’ve read my blog at all in the past you know I have a borderline obsession with the concept of starting with why (Hat tip to Simon Sinek for introducing me to this concept). Obviously this applies rather easily to community environments where individuals volunteer their time and join a particular “tribe” because they have an enthusiasm for the shared central tenets of the group. But applying these same concepts to a “for-pay” business arrangement it becomes even more interesting.
In this compensated environment “starting with why” begins to rebalance the equation. When a business is able to start by sharing their vision and the reason behind the mission they are undertaking they are able to identify those eager individuals interested in fighting for the same beliefs. In this way, even businesses can begin to build a culture and an organization which forms a tribe instead of merely providing an occupation. And things begin to change.
The best and most incredible companies are those who have discovered this principle. These are bastions of business who are intent on building an empire. A company that is “built to last”. This is by no means an easy task and for every single success story there are hundreds of corporate carcasses strewn by the side. This is such a rare trait we frequently celebrate those who have discovered this holy grail of passionate, empowered workers. We study them in business schools and we analyze their every move. Too often in doing so we take a far to analytical approach and quickly neglect the rather intangible values which have predicated such success in the first place.
But there are enough of these exceptions to the standard to lend credibility to the possibilities. And so we continue to strive. We strive to identify the roots for success, and we strive to implement them in our own businesses. And although this success looks different for each business the common thread of empowered employees lies at the heart of most.
Empowered employees are those imbued with passion for the vision and motivated by the same foundational “why” as the business.
More than monetary gain
I think it is only appropriate to end this post with one last commendation. While the reasoning I have listed above tends to appear at first blush to serve only the needs of the business and encourage financial reward, the truth is much, much greater. Far more than any balance sheet, or revenue bookings, these passionate people build companies which stand against the test of time, providing futures for thousands of others. Creating opportunities for the improvement of life and the enablement for personal success.
What is the true power of passionate people? As the famous Mr. Jobs shared in the now timeless motivational video: These “crazy” ones are the ones who change the world.
June 3, 2018
Saelos Sunday Stuff
Here we are on another weekend, and it sure feels like they come fast and furious these days. I don’t know if it’s just me or if time is actually speeding up. (And anyone that dares to suggest this relativity has anything to do with my age will be summarily disavowed.) Regardless, it’s Sunday and as they have come to be affectionately known, it’s a Saelos Sunday.
There are so many things I’d like to share with you but in an effort to draw your attention to one particular and important statistic I’m going to focus on only one slide. In this way we can share in the excitement of the meaningfulness of these statistics.
Before you get all stressed out because I’ve use the word “statistic” more than once in the previous paragraph, let me calm you down by sharing a picture with you (pictures make everything better).
Now, I confess I said I would be focusing in on “only one slide”, but I’ve been a bit sneaky — if you’ll notice this slide actually shares two very important facts in a single slide. Let’s first look at the downloads. It’s quite exciting to see the numbers climbing so significantly with each release. This means the world is beginning to discover Saelos: a new open source CRM.
As you can see from the picture, the Beta 3 release had only 32 downloads, Beta 4 had 86, and then Beta 5 scored an overwhelming 395 downloads! Now, we are currently in the middle of Beta 6 and we’re on track to see more downloads than any other previous release with 306 downloads.
But the stability of Saelos is the second critical factor that is displayed in the slide above. You’ll notice that with each release the time period before the next release has grown. Whenever there is a lengthening time between releases it usually means one of two things, either the software is not being developed at the same speed as previously, or the bugs being uncovered are becoming fewer and fewer.
I am happy to report in Saelos the number of issues that have been uncovered has been shrinking with each subsequent release. This shrinkage is quite common in the development of a product, particularly one proceeding through a beta process. As a result this slows down the number of releases and also demonstrates an exciting fact: Saelos is getting close to being released as a Release Candidate.
In case you’re curious or need a refresher on process. A software product following proper versioning goes through multiple beta releases (determined by the number of issues uncovered in each release) , then a release candidate, then a stable release.
As I mentioned, based on these statistics Saelos is getting close to a Release Candidate. This is an exciting moment. If you are currently using Saelos then this should be a welcome announcement — a stable open source CRM ready to be implemented in your production environment is coming soon.
If you’re wondering what it will take for this to happen then I’m glad you’re thinking about it! Our community needs issues reported when there are bugs found (this can be submitted on GitHub); fixes for those issues submitted as new pull requests (also on GitHub); and any last minute feature requests (with code attached!) to be included in a stable release.
Lastly as you prepare for this upcoming release you should make sure you’re keeping up-to-date with the announcements being made. There are several ways you can do this and I believe in though our community is still quite young we do a great job communicating on a variety of channels. Pick your preference: You can subscribe to the Saelos email, join the Slack group, or register your account on the website (truthfully speaking it wouldn’t hurt anything to be around on all three).
One More Thing
I know it sounds a bit forced but forgive my headline nostalgia for a moment. There is one last thing I’d like to share in this Saelos Sunday update. Even though our community is very fresh we have already seen incredible volunteers contributing in a wide variety of ways. Sometimes I just have to sit back and contemplate the awesomeness of those individuals who believe in my vision, who personally agree with what I’m trying to accomplish and are willing to join forces with me in reaching for these lofty goals.
I’ve spoken before about the power of the “first follower” and this is a perfect example of how relevant and important these early adopters, advocates, and strong believers are to our success. This week in particular I’d like to draw special attention to one special Saelos Superstar.
Luiz Eduardo has contributed countless hours to improving Saelos through code, through distributions, and through community growth. His dedication to spreading the Saelos Story far and wide is evident in the vast and widespread work he has undertaken on behalf of our community. I hope you’ll join me in thanking him for his hard work and dedication to Saelos. And I trust his example will encourage you to find ways you can also become more involved in the Saelos community. (Not sure where to start? Drop me a line and I’ll be happy to give you some ideas.)
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 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 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 29, 2018
Saelos Sunday Update
Well this is an exciting update to share. Saelos was announced and released on April 15. Today is April 29, exactly 2 weeks later. Because everyone is busy I’m sure you haven’t been able to keep up with the progress the same way that I have been so I figured the best thing to do is to write a short update post to give you a sort of a status update on how things have been progressing.
This is of course very early beta software (some would even call it alpha, simply due to its newness) but the status of the code causes me to suggest that we have moved much quicker into beta software status.
These numbers are constantly changing as you can imagine so please don’t put too much faith in any one metric. Rather I’d recommend looking at them as a brief snapshot or glimpse into the growth being experienced. And let me be the first to tell you that growth is evident and exciting. Saelos is moving along at an excellent pace and perhaps even more exciting growing we’re moving forward in a very sustainable fashion. You’ll see why after I share a bit more information.
Okay, here’s a quick stats list:
- Downloads/Sites Created: 264
- Releases: 5 Beta Releases
- Slack: 22 members
- Website: 49 members
- Pull Requests: 0 open / 7 closed
Wow, those types of numbers and to be only 14 days old is quite exciting. Perhaps the last statistic is the one that speaks the most to me. As an engineer at heart I am always looking for indicators that other developers are also interested in and willing to contribute to a project where I am involved. The number of pull requests submitted by community volunteers in the very first couple of weeks of this project is indicative of several things – including the ease of readability of the platform and code.
In fact, even better, I saw 4 community created pull requests in the first 24 hours! (Of course a couple of these were minor issues, but still, the point remains the same: the software is easy-to-read and modify.)
I should also mention the new website just briefly since I realized I never shared anything about that earlier (I’m not lying, the time is just flying by these days). I also launched https://www.saelos.org this past week which gives an online home for conversations, announcements, and other things related to Saelos. You should join in so your voice is heard and you’ll be able to share your ideas for future releases of Saelos and begin getting involved yourself (Are you interested in documentation? If so, we should talk).
Beyond the highly notable achievements listed above occurring within the first 2 weeks of release an additional exciting contribution came in the work of Luiz who has already created and taken lead for maintaining a Saelos Docker container. This makes installation and setup of a new Saelos instance incredibly fast and simple (and significantly encourages new users to try Saelos).
The next obvious question is “now what?” What release comes next and when? This question is a little harder to answer simply because when dealing with beta software new issues or uncovered all the time and the desire is to create as stable a product as possible before releasing a 1.0 stable. Currently there are about 10 issues open in GitHub but of course they vary in difficulty and time to implementation.
The next more imminent milestone is the release of an RC (Release Candidate). At this point I’ll have a pretty good idea of what the 1.0 Stable will look like and this release will be a pre-packaged version to begin fixing any last minute bugs before release. This RC should be fairly close to stable. At the moment I don’t have a solid date for that release because we may iterate through a few more – Beta releases first as we knock out issues and make system improvements.
The next beta will more than likely be released next Friday afternoon or Saturday as time permits. I am hopeful to see a number of the open issues resolved with this beta and I can share those fixes as they are merged.
The last thing I’ll leave you with for this quick update post is a very simple and easy call-to-action. If you like this content and want to be kept in the loop regarding all things Saelos then you need to fill out this short form and you’ll get an update newsletter direct in your inbox each time once is created.
That’s it. I’ll do my best to keep the Saelos Slack channels updated as well as the newsletter and if you are following my blog here, you’ll also get updated whenever I post something here too.
Have a great rest of your weekend and I’ll see you in Saelos!
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.
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.
June 30, 2016
First Follower FTW
Recently a humorous in-office chat unfolded on our #cooler Slack channel. It began simply enough. I posted a random photo that I found to be funny due to an optical illusion.
This lead to one of our team posting this humorous reply.
What happened next caused me to remember a post I had meant to write but forgotten about. This is the message which pushed me to write this post.
It seems rather innocuous and unimportant even, but the opposite was in fact true. This was the first follower. Why you might ask? Because this post lead to this.
The leader was the first poster, they had an idea and they shared it. But the first follower, the second poster, they started the movement. They supported the idea and turned it into something more. That’s a very practical example now let’s look at this concept of first follower in a bit more detail.
What is first follower
The first follower is a phenomenon I learned of first from a TED talk by Derek Sivers. In this talk he discussed a popular viral video which you can watch here if you feel so inclined. Here is the bottom line if you prefer a tl;dr version.
The first follower is the hidden leader of a movement. They support the vocal initial person who began doing something different. The first follower lends credibility, support, and raises awareness. The first follower takes the focus off the person and places the focus on an idea. This is the moment when a movement behinds. Let me rephrase that another way.
“A movement begins when the focus shifts from a person to an idea.”
Why be a first follower
Clearly there is an immense amount of power held by the first follower. This person is the true hidden driver behind revolutionary change. Their input might not always visible or even publicly recognized but the power exists. The first follower recognizes they have the ability to support and promote the idea creator. Being the first follower requires bravery. At this point the idea is new, young, and unaccepted. The general audience has not yet accepted the idea being promoted and the creator is a lone voice proclaiming their message. The first follower therefore holds an immense amount of risk in accepting this idea and following the promoter. But the power, the responsibility, the opportunity to make an idea a movement lies in the hands of the first follower.
When to be a first follower
Because of the amount of risk associated with being the first follower there should be some guidelines followed before blindly becoming a first follower. Here are a few general questions to consider before assuming the role of a first follower to an idea.
Do you agree with the idea?
Sounds basic right? But before you follow someone or something you have to determine that you fundamentally agree with what’s being shared. The world today is so connected and accessible that anyone can share any random idea or thought. This does not mean every idea is worthwhile or worthy of becoming a movement. Critical thinking is required.
Do you feel passionately about the idea?
It’s not enough to simply agree with an idea you need to feel passionate about it. Is this truly something you believe in. Keep in mind is the turning point for the idea and its creator. This holds the potential to turn an idea into a movement. You should feel passionately and willing to truly support and back the idea.
Are you prepared to support the idea?
This question should be an easy one to answer if you have asked the first two questions but it’s still important to ask yourself if are ready. Supporting an idea in its infancy may result in rejection from others who don’t follow with you. Even more difficult is the acknowledgment and acceptance you may even be ridiculed for your belief and support of the idea.
If you answer these three questions and you’re ready to move forward then keep reading.
How to be a first follower
There are many way you can demonstrate your support and approval of an idea some are easy and some require more work. Typically the more difficult the way to demonstrate your following the greater results you’ll experience.
Be a silent supporter.
This may seem like passive support but in the early days of an idea (before reaching the critical mass) even the silent support is important to the eventual success of the movement. Silent support might be as simple as a “like”, or maybe a public acknowledgement of someone else’s verbal comment.
Be a vocal supporter.
The next level of first follower involves vocally supporting the idea. Again slightly more risk involved as you are publicly sharing your agreement with the idea. This might mean resharing, retweeting, or verbally affirming what someone else says or does.
Be a secondary creator.
This is the most difficult level of first following. At this point you we no longer merely supporting silently or vocally but you are creating and sharing additional supporting ideas. You are taking your support of someone else’s idea and you are owning the idea at this point. This is opens you up to your own level of ridicule as you are now becoming a bit of a public leader yourself. This is creating variants of the idea and sharing them all with the purpose of growing the support for the original idea.
The bottom line is simple: be a first follower. Start a movement. Don’t feel like you must create an idea to be successful. Instead as this post and the supporting documentation and research shows – you can be the true force that makes an idea into a movement. Find those ideas you believe in, passionately believe in, and support them, advocate for them, and build on them. Follow them.
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 12, 2016
A Better RedHat Model to Replicate Today
If you look at what made RedHat successful you will find a unique story. Unique in a variety of ways. First, the marketplace was dominated with closed source box software and lacked any open source freely available products. The dominant players sold licenses of a single software version. Secondly, the notion of free software but paid support was practically unheard of. Again, the dominant players would offer a paid product with free support. RedHat offered a reverse on this model. Many people are aware of this part of the story. Many understand the implications of free software and paid support and how enticing this proposition was. It is easy to see how this caused the global market to shift. Free software regardless of the support is a powerful motivator for someone to begin using a product.
But this is where the majority of people think the RedHat business model ends. This is the point at which many new companies attempt to mimic the supposed “RedHat Model”. And this is the fallacy. Because this is not the complete RedHat model. Look deeper and you find a much more detailed strategy which helped to make RedHat successful. Even still what follows may not be a complete picture but should provide at least a slightly more detailed view of the story.
Though the “free software and paid support” model does play a role in the overall strategy there are many more levels of opportunity present. This is the key to a modern day RedHat model. These often overlooked additional features are how a current open source model can replicate the success found in RedHat. Here’s a better look at the RedHat model.
RedHat offers a freely available product; an amazingly good codebase available for anyone to download. Then, in addition to offering support for this product RedHat provides a wide range of additional services offered as add-ons to effectively make things easier for businesses. Note what this does not mean. This does not yield a sub-standard or crippled free open source code. The free source code is every bit as powerful and is the basis on which RedHat builds everything else. Rather than maintaining a separate and “better” product RedHat takes away the pain of compiling and building the finished product. Then they offer support for this product (everyone sticks on this part)…and they offer additional services focused on specific market segments.
This is a brilliant strategy for a number of reasons. This approach still supports and encourages open source completely. This provides anyone and everyone regardless of the size of their business or their revenue the opportunity to use incredibly powerful software. This allows a global community the opportunity to find and improve the software and to implement improvements that meets the goals and needs of the majority. This strategy empowers people. And this strategy also allows a successful business to be built around this product. But this is just the beginning. Structuring things in this way paves the way for other businesses to find success and also be built on this same amazing source code.
RedHat is more than a support company. RedHat is an open source company that empowers people regardless of size. They have turned an industry on its head and revolutionized the way software could be released for free and still be profitable. This strategy, this complete strategy, can be replicated. This is how you can be successful today replicating the RedHat model. Look at the bigger picture. Don’t neglect the community. Don’t cripple the core open source code. Build supporting services to meet specific needs. Empower people.
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.
September 15, 2015
Finding the Right Fit
(Building An Exceptional Team)
Part of my duties in my day-to-day life involve finding the next great talented person to join our team. I don’t think by any means I am an expert at this, but I have been told on numerous times that we have a great team. (That’s not me, that’s the team believing in what we do). Remember these are not just empty chairs floating around and in need of a warm body. These are highly important positions for your team. Every single team member is important. When it comes time to build a team or fill seats, whether that is for a business or for a community there are several things I think are incredibly important. Some of these qualities might be surprising and some may be noticeably absent. I would like to share with you the five qualities I seek most often when looking to build a team.
These might be different for you and you may find mileage may vary depending on the industry or the focus of your company or organization. But I believe the following five qualities are a great place to start when building a team. I’ll give them each to you quickly and explain why I feel they are important.
Of course everyone is looking for an honest employee or co-worker. No one wants to think they are working with someone that will lie, cheat, or steal (remember though: if it’s in the refrigerator and unlabeled- that’s fair game). But in seriousness, an outstanding team member must have outstanding character. They should be not only honest and trustworthy but open. No, not the type of person who blabs every little detail about their personal life. But rather, they are quick to share their concerns, their potential problems and their work struggles. They are open and transparent in both successes and failures. I believe this is one of the most important character traits you want to find.
I love determined people. I am highly determined. I’m motivated. I love to work with people who are determined. They take the tasks they are given and they “make it happen”. Sometimes today that feels like an overused phrase but this determination to accomplish things is important. Immediately you may think the opposite is laziness, but I disagree, the opposite of determined is disinterest. They may be present and performing their job but without determination they are not the outstanding team member they could be. Determined does not mean working long hours every day either. Determination may require an occasional late night or at the least the willingness to put in extra time when the situation arises, but being determined is not being a workaholic. Being determined is more about a state of mind.
A great team member will be proactive not just in doing what is required of them but seeking out other ways to help the team succeed. This state of being proactive means being a thinker. Proactive team members are always interested and engaged, they want to see great things happen because they believe in what they are doing. But more about that deep down belief in the next point. Proactivity isn’t just doing more work or finding more work to be done. Proactivity means a sense of alertness to the team environment and the outside community. What does that look like exactly? I’m glad you asked. Here is a simple three word phrase that I like to use to describe this concept. Proactive means listening. Many consider listening to be a reactive or passive activity. But if you are actively listening to what’s being said what you’ll find is you are essentially hearing what could be next. If you are actively listening you are proactively building the future.
Yes, an outstanding team member needs to be caring. I don’t mean a touchy-feely, let’s all hold hands and dance through the fields type of caring. But the outstanding team member needs to care deeply about the team, the organization, and the community. How does this happen? Simple. When you build a team surrounded about a shared belief system. When you find those team members who see, understand and share the vision of the team then you will have found an individual who will care. Let me describe this quality by sharing another opposite. The opposite of a caring individual is an apathetic person. They show up, they do their job, and then…then they leave. They only punch the clock; these individuals lack determination, they lack the proactive understanding about the underlying foundation for why you do what you do. They don’t care. A caring individual must be deeply motivated by the reason why.
The last character quality I like to seek out when identifying exceptional team members is their ability to get excited. Too many times I think the idea of excitability gets a bad rap. People label someone as excitable if they are easily agitated, that’s a completely different word. When I say excitable I mean someone who’s passions can be stirred. They are caring, they understand the vision and they are compelled by the vision to accomplish the mission of the team. And this excites them. This drives them and gives them determination. to be proactive. I love to see someone get excited about what they are doing. This speaks to me. I see their passion and this passion, this excitement, is contagious. It spreads throughout the team. If you have a team member that does not have the quality of excitability then the team as a whole suffers. But when excitement works its way through a passionate team then each person feeds on that excitement and the passion builds, and builds, and builds within the team.
And those are five of the key qualities I like to look for when building a team. When I find someone with those traits I have a pretty good feeling they will fit within the team. They will share in the culture of the team. There are some great examples of company culture and team culture which I follow but I will refrain from commenting or sharing my thoughts on that aspect of hiring in this post.
You may have noticed a few qualities conspicuously missing from this post. No I haven’t neglected the importance of formal training, potential salary requirements, or the hard-working nature of a team member. But these are secondary qualities. They play a part but they are not what I look for first. I want to build a team that will last, a culture that inspires, and a community that grows for years, and decades to come. When I meet someone with the five qualities I listed above the result is usually someone who will not only fit into an amazing team but become an amazing part of the community.
July 30, 2015
An 8 Step Onboarding Process
One of the hardest thing in growing any community is not finding new volunteers (though this can be difficult), the hardest thing is encouraging those new volunteers through the initial process of contributing and continuing those contributions over time.
The Concept of Onboarding
This process of bringing in new volunteers and welcoming them into a community is labeled as onboarding. Onboarding is not a difficult concept and every single role in every single business undergoes some form of this process in the beginning. This is the process by which the new individual “learns the ropes”, understands the job description, identifies the work to be done, and determines a way to accomplish that work.
Many jobs have specific processes to accomplish this onboarding task and most companies outline them clearly in their manuals and job training programs (usually run by HR). Unfortunately while in corporate environments this is regularly seen as a necessary part of the process it is far too often neglected in open source communities and volunteer organizations.
I’ve seen this firsthand when communities encourage new volunteers to join, they beg for new helpers, and then they strand them. Oh, they don’t mean to strand them but they inevitably do. They leave them behind to fend for themselves. There’s many reasons for this and these organizations never mean to intentionally abandon their new volunteers but it happens; and it happens far too much.
Identifying A Process That Works
So if we can recognize there is a problem then we can formulate a solution! I propose the following 8 step onboarding process for community volunteers. This won’t be comprehensive and shouldn’t be applied blindly to every organization but I believe it gives a basic outline which can be used and adapted to meet many of the current problems found.
Step 1: Immediate Engagement
The very first step in the onboarding process is the easiest and the one step that most every organization understands and does fairly well. Every onboarding process must begin with finding new volunteers and immediately engaging them. Here’s the important thing to consider at this step: The organization must have someone responsible for reaching out, engaging, motivating, and encouraging new volunteers. Again many communities understand this importance and do this remarkably well and with determination. It’s easy to encourage people to join. It’s relatively easy to smile and cheer on an initial interest from a volunteer. For the sake of this article I will assume you are this person.
Step 2: Baby-Step Accomplishment
This second step is an important one. The same person (you) who initially engaged and encouraged the volunteer should provide them with a basic “task” or “responsibility” they must complete. When the volunteer has done this first step they need to be met with praise and recognition. The encouragement to get involved turns into praise for a job well done. Remember that no accomplishment is too small and nothing is too insignificant to turn into an opportunity to encourage and praise. You want to motivate and encourage continued engagement. Recognizing the time someone spends to accomplish a job is the perfect way to demonstrate this.
Step 3: Group Introduction
Once the volunteer has been engaged and has completed their very first minor accomplishment (and I do mean minor, this is something very easy to do!) the next step involves introducing them to a larger group of other individuals. You want to introduce them and make sure they feel welcomed by others. This is where community growth becomes a team-effort. Not only do you engage with the new contributor but you must also engage with existing team members and volunteers to ensure they are welcoming and friendly to the new person!
Step 4: Peer Connection
Of course you know that not everyone will make immediate friends with everyone else. Things like personalities, culture, regions, languages, and timezones all affect personal relationships. This makes some connections harder than others. Some relationships form naturally and immediately make lasting connections. Others just don’t. The important part is to identify one or two individuals in the group where a connection has been made and ensure they grow. You will need to connect directly with both the existing volunteers and the new volunteer. You are actively engaged in enabling and empowering these relationships.
Step 5: Second Accomplishment
The next step in this process of a successful onboarding means taking the time to observe and watch for the second accomplishment by your new volunteer. At this stage the peer connections you helped establish previously should be the primary points of contact within the group or team for the new volunteer and should take the lead in identifying tasks to be completed. They should also be the ones to encourage, support, and praise the new volunteer. Your job is not done however, you will need to watch and be ready to again recognize the work completed. You are a cheerleader and encourager.
Step 6: Engage Someone New
Here we have a turning point in the onboarding process. The new volunteer is no longer a new volunteer. At this point they are familiar with the organization, the team, the project, and the various other aspects of “how things work”. They have not yet become seasoned experts but they are highly knowledgeable. This is important, at this point they have a maximum potential impact for further growth. Think of it as the intersection between knowledge and passion. This intersection is the perfect time to have them begin engaging with new volunteers. They become actively involved with encouraging others to get involved. (The new volunteer is beginning to fulfill Step 1 above)
Step 7: Identify Opportunities
Our new volunteer is now officially considered no longer new. They are one of the key members of the team and serve in a variety of capacities. They now are available to work as a peer connection with new volunteers brought into the group. In addition, because of their tenure and involvement they are very aware of opportunities for growth within the project or community. They are active in identifying these, solving them, and delegating them. They provide these items to others who are currently at Step 5, their second accomplishment. (Remember: peer connections work to provide the tasks for that step).
Step 8: Advocate
We’ve reached the final stage of the onboarding process. I realize it feels long and exaggerated but this process is truly all part of what makes a community grow strong and for the future. This final step involves the volunteer engaging, motivating, and encouraging others. At this step the volunteer has been turned into…you. And thus the cycle completes itself and the community begins to scale.
Our goal in creating an onboarding process is to see the community flourish and grow. We all want to see viral growth and watch our volunteers thrive not only within the community but also personally. This 8 step plan for onboarding volunteers will give you the power to scale your community and increase your engagement with your contributors. Take this process, implement the specifics unique to your community and establish a system that will empower your volunteers! And of course I’d love to hear your stories of your journey!
July 3, 2015
The Price of Free Software
Let’s talk for a minute about the topic of free software. As you may know I am deeply involved with the Mautic community which offers a free marketing automation platform. This platform is free, open source and available for immediate download by anyone interested. I am thrilled to be able to play a part in this community which seeks to support businesses, organizations, and people in their marketing efforts without asking for anything in return.
I have over a decade of experience in this type of environment as I’ve previously volunteered my time in the Joomla community as well as spending time in both WordPress and Drupal communities. All of these communities are centered around a free product and also an open source one. Their content managements systems can be downloaded and installed and used with no payments made. These are merely three additional examples drawn from personal experience, hundreds if not thousands of other communities exist to provide free software. This leads to an inevitable question. Is free software truly free? What is the hidden price of free?
I’m going to break this down into three sections. First, we’ll examine monetary costs, second we’ll look at secondary costs, and lastly we’ll look at future costs. After each section we’ll draw a conclusion.
The Monetary Cost of Free Software
This first point may seem almost ludicrous since we’re discussing free software and by very nature free software implies that there is no monetary cost. However, unfortunately in some cases free software is limited software. These types of free software are poor restricted attempts to win customers by offering something free which in truth is merely a hint or shadow of what the software should do.
This is a uniquely cruel form of torture and one which should be abolished and abhorred. No software intentionally shackling or tethering the user under the guise of free software should be allowed to exist as free software. This kind of “free software” does indeed have a very high monetary cost and unfortunately gives all other types of free software a bad name.
Conclusion: All free software has not been created equal.
The Secondary Costs of Free Software
There are, of course, additional costs associated with a software platform that exist far beyond the money spent in acquiring the software. These are indeed very real and should not be forgotten. Let me name just two of these secondary costs for you.
- The Learning Curve: With free software there is a learning curve which the user must overcome before they are comfortable using the platform. This learning curve requires time and dedication. This time can be extremely expensive. And yet, I would challenge you with a question. Could I not remove the word “free” from the first sentence and the statement would remain the same? “With software there is a learning curve which the user must overcome before they are comfortable using the platform.” Yes, this statement is also true and valid.
- Training & Support: Free software may not cost for its use, but there are training and support expenses which result from the use of this software. And again, these costs would be equally attributed to paid systems as well. Every time software is implemented there is an opportunity for training and support fees to be provided.
So we see that there are opportunities for additional secondary costs associated with free software. There is something though that I touched on briefly in the second part of the Learning Curve cost. The time involved in learning a new platform, of any kind, is a cost that can be most exorbitant. But here’s an interesting suggestion. When dealing with a free community full of active volunteers this learning experience can be much aided through network of others. This type of learning can never be accomplished in the same volume by a paid software company. Thousands of volunteers working and participating on the improvements of the software able to answer your questions, offer advice, and improve your understanding makes your learning curve easier with free software.
Conclusion: All software has secondary costs.
The Future Costs of Free Software
Here we explore the potential future costs as a result of implementing free software. Some would suggest that because free software is free it must then be unsustainable and more liable to disappear in the future. I find this somewhat ironic. These communities which exist purely for the growth and improvements of the software and are not tied to a for-profit business serve to exist for far longer times. Successful communities will be able to continue without fear of failure due to lack of funds. Now free software where the code is also open source means the code will be forever in existence and available to everyone, anywhere. And lastly, due to the sheer size of free, open source communities volunteering there is a much larger development pool capable of continuing on the progress and improvements to the software.
Conclusion: Free software is not bound by for-profit corporations for future existence.
I am not foolish to assume that all free software is as wonderful as the software I listed at the beginning of this post. These are both free and open source software tools which are a bit different from just examining “free software” however, my background and experience leads me to speak to this type of free software. There are of course other, far worse examples of free software which harm the concepts of the software listed here.
And lastly, you may notice that the second item listed is the only example where actual costs may exist. This is indeed a cost associated with free software. However, as I stated this cost exists regardless of the nature of the software. Both free and not-free software hold these secondary costs. Therefore I believe it is fair to say these costs are valid to be disregarded when valuing the cost of software since they will exist in any situation.
I conclude then that while there may be costs associated with free software you will find that these costs are far, far less then in other situations and ultimately you will still find free software to be more cost effective than the alternative.
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 24, 2015
The Secret to Growth Hacking
Recently I had the great privilege to travel and speak at the 3rd annual CMS Africa Summit. I was asked to deliver two keynotes and the second one focused on the idea of growing a community. The session title: Building Powerful Community Networks, was given to me by the event organizers but I believe it was quite insightful on their part.
Below are my slides from my session. While usually I offer a more extensive write-up to associate with a slideshare like this I believe these slides speak fairly well for themselves. I trust you’ll look through these slides and you’ll be able to easily see the message I shared.
I believe deeply in the power of communities and I love researching how to scale community growth. I hope you’ll enjoy glancing through this deck and exploring what I see is the secret to growth hacking.
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!