What the #S@&%*! is up with the Elephant?
If you’ve visited our Gradle.org web site or Gradle.com recently, you may have noticed the appearance of an elephant (and a bird) and some new sayings.
You’re probably wondering what this is about.
There are two stories to tell, the story of:
- Gradle Inc. (the company and what we are up to.) and
- Gradlephant, the new elephant logo/mascot
First and foremost about
Gradle Inc. is the same group of people who you have known in the past as “Gradleware”. It is the same company founded by Hans Dockter and Adam Murdoch, who are the CEO and CTO of Gradle Inc. respectively. So first of all, there is no change to the leadership. One positive change is that we continue to grow the team and add new core Gradle Engineers, in fact we are hiring now.
Gradle Inc. continues and expands on its commitment to Open Source software by investing more and more resources. We continue to have strong Open Source partnerships in Silicon Valley including Linkedin, Netflix and many others which can fuel our deep investment into the Gradle Open Source project.
To give you an indication of the kind of reliability and consistency you can expect from Gradle, I present you to all of the releases of Gradle since the release of Gradle 0.9 on December 19th 2010 (wikipedia info). As you can see, Gradle Inc. (previously Gradleware) has been exceedingly regular in its releasing of Gradle versions and we are committed to continuing to do so, in fact we are already building Gradle 2.9 right now.
The new elements of the Gradle Inc. story are related to our company mission and product portfolio. Gradle now has a motto called “Build Happiness”, which we will talk about shortly when we introduce the elephant. Gradle Inc.’s mission is to transform the software industry through technology for automation in software development and deployment (DevOps).
Because of this mission, we are launching a perfect compliment to Open Source Gradle, which is the Gradle.com SaaS offering. Feel free to check it out at http://gradle.com.
Gradle now has a new logo and mascot, the Gradlephant.
You might find it a bit odd to see him swearing if our motto is “Build Happiness”. We at Gradle recognize that the build is often the source of contention because there are often lots of inefficiencies and downright broken aspects of the build in many organizations. This results in confusion, long developer onboarding times, lack of developer “flow” or productivity and eventually lack of developer morale and even loss of team members to competing companies. These hellish inefficiencies include:
- Long build times
- Endless Bug Regressions
- Broken Build Processes including blaming and finger pointing
- Long Code Freezes
- Build Script “Chaos” and unmaintainable scripts
Just to name a few. These we refer to as “Build Hell”. The elephant is swearing at Build Hell in all its incarnations and the process of swearing at broken #S@&%*! is the beginning point of being able to build happiness.
So the Gradlephant is a hard working animal, but sometimes prone to swearing at bad processes and systems. You may notice in certain places as well that the elephant is accompanied by a bird. This is because the Elephant represents “Build” whereas the bird represents “Happiness”. There are also scenes in which there is an elephant only, but no bird. “Elephant, no bird” is what we call those situations where there is a lot of grunt effort needed and we are just not there yet in terms of happiness.
When Gradle Inc. talks about Build Happiness, we mean a specific definition of Happiness. We believe that Build Happiness is the result of three components:
So pleasantness is the least significant and durable form of happiness at work. The other components are FLOW and MEANING.
We define meaning very specifically, we mean that you are applying your unique strengths (as a developer) and growing virtues in service of something larger than yourself (your project).
By flow, we mean that feeling of productivity that is immersive (involves losing track of time) where your skill is adequately matched with challenge. Not enough challenge can result in boredom, whereas too much challenge can result in anxiety. We believe that flow is essential to software developer productivity, and we feel that restoring flow should be a key responsibility of technical management.
The kind of flow we are committed to producing for developers is the same kind of flow most developers experienced with their very first computer. The kind of flow state of seeing your first software run and by debugging this software as a kid or teenager. This is the excitement that got you into the software industry to begin with.
We know that the topic of build can be contentious and can even produce swearing. Most people just want the build to work seamlessly, and they don’t even want their development teams to be aware of it. We continue to invest and develop our tooling to improve their craft.
Flow, Performance and Happiness
One thing we know developers want is a fast build. We understand the huge value of a fast build as it is essential for maintaining developer flow. Developers want to know as quickly as possible the status of code changes and when they can be put into production, and they want all the tedious chores between code change and production to be automatically taken care of.
We are also aware that the build is never fast enough. This is why Gradle Inc. continues to make significant investments in performance including the Gradle Daemon and incremental build capabilities and we continue to work on parallelization, caching and other techniques. We are in particular working closely with the Google Android team to make Android builds much much faster as well.
We feel that Gradle is already fast compared to some of the less modern build environments available, but we know we have much more improvements to make. Because we build Gradle with Gradle, we are able to release Gradle versions quickly (see chart above) and we are committed to more performance related improvements in the next six months.
We wanted to close by thanking the Gradle community for sticking with us over the years. We have a very dedicated group of people who have contributed to Gradle and we see active engagement in the form of new plugins (over 600 plugins now), activity on our discussion forums and of course pull requests.
What about the “gear”?
We have a lot of fond feelings for the “Original Gradle” logo (we call it “OG”)
We will continue to support our roots with this logo, and perhaps do a limited edition shirt run featuring this OG logo. Please get in touch with us if you want any OG Gradle stuff, but of course we haven’t made any yet and supplies may be limited.