Hi all, a handful of folks from Canonical (myself included) want to organise a call/open office hours event for the community. The idea is to have a friendly chat over our experiences with Juju, our weeks and, if someone has any questions, offer technical tips on the Juju and charming topics.
How do you folks think we can structure this? Even if you wouldn’t like to take an active role, what sort of topic would you like to hear about?
[Canonical employee hat off]
If I may answer my own question and share a bit of my personal views on the topic: I absolutely adore the idea that Juju has the potential to really democratise state of the art cloud architecture and open source apps.
As all pages about free software discuss, the concept of “free” goes far beyond the monetary value of something. In the case of Juju, I think that “free” means that not being a DevOps specialist shouldn’t stop you from building infrastructure that will deliver your world changing idea to a global audience. And if you are a DevOps with 12+ years k8s experience, you still should have access to the operational know-how of thousands of other specialists.
It’s feels good to work on socially impactful projects and I would like to talk about that in our calls 
As you identified with your donning and subsequent removing of Canonical hats, I think it should be structured separately to serious, technical, product, stuff. 
I would like to here about this:
I absolutely adore the idea that Juju has the potential to really democratise state of the art cloud architecture and open source apps.
So I’d say, speak from the heart and begin at the start. Why Juju? What even Juju? How can I even Juju? Juju? Eh? Tell me, us, the Juju community, why you’re a contributor? 
I like this idea a lot.
The Juju office hours petered out as folks moved on, or moved to different teams. I think that it would be wonderful to bring them back, with a focus on project ideas, beginning/intermediate tips, and general community engagement.
I can talk to the team about how we might do this, balanced with all the other stuff on our plate.
That’s awesome info, thanks for sharing it. Were these office hours strictly technical or more like an informal chat? How did you folks structure it? --someone would just come with a question and you would help them to debug it?
The office hours streamed on YouTube. It doesn’t look like notes and materials are trivially accessible, but I will keep an eye out for them.
Wow, those look fun 
On Google Hangouts no less! We can definitely learn some things, are you in any of them @pengale ? Couldn’t see you at a glance
The brutal truth at the moment is that most of the community engagement comes from “Canonical Staff”.
This wouldn’t necessarily be a bad thing, but it does deserve a moment of thought:
I’m not a Canonical staff member and I don’t get payed by Canonical. So I can say from an independent point of view, that Juju is great for both personal use and professional use.
Over the years my interest (personal, professional, technical) in Juju has grown, expanded and merged. That’s why I care about where Juju moves forward and also how.
How to move forward
My opinion is that Juju needs a community governance which is more detached from Canonical. It needs to be able to have capabilities, governance structures and be able to set priorities that are at least to a degree independent from Canonical in a truly open source spirit.
Canonical has a extremely important role here, since its in fundamental control over the project at the moment. Economically, Governance, tools, priorities, staff and infrastructure. Also, probably 100% of the skills to nurture and develop open source communities. So, I’m super glad that this discussion now starts to happen.
But I also don’t hear much opinion from “outside” of Canonical. That also raises questions and concerns. I do know what a few previous community members has raised voices and tried to make way. Those voices has gone silent. That is worry-some and an indication that something is wrong. That is really bad since that is a difficult boat to turn.
I think that Canonical letting go of part of the governance of Juju, handing that over to a community of some sort would be a possible path.
Where to move forward
This is where community activities play an extremely important role. To develop Juju forward in an open source spirit, the community engagement in “where juju moves” is picked up and understood within those places. I’ll try to participate as much as I can to discuss this with the community. I have alot of opinions on where Juju could move, which I’m happy to share but also listen to others that most probably have great ideas. Having Canonical on board, in a driving seat, is of course a primary key to success.
Also here, Canonical letting go of some of the setting priority and handing that over to the community governance is equally part of a vaild path forward. How that process could look like etc. is way beyond my competence but I also know that within the ranks of Juju are an army of really good community-builders and open source warriors what likely knows how this show should go on.
The initiative for a community meetup is a fantastic thing which I’m 100% pro! @bianka @davidbooth @anastasia-macmood
I think you’re exactly right. Non-Canonical community representation is needed.
I’m on the community team at Canonical, so quite far away from Juju as a product, but very interested in what developers and the community are thinking.
I/we would love to talk to you and the aforementioned community-builders and open-source warriors about how you would build out the community so that Canonical is a contributor, not an owner.
I’m entirely new to this forum but if you know said builders and warriors, could you point them at this thread or to me or @pedroleaoc directly so we can set this meetup up?
Hi,
I’m just adding my 2 cents here, as a non Canonical staff member and growing user of Juju.
To be honest, I think Juju is mostly lacking in notoriety.
This is a great tool (just as MaaS) but ask around yourself in the “DevOps community” and at best, you’ll see people barely knowing the name.
Everybody knows Terraform, Ansible, Salt, Puppet, Chef, Helm, whatever you name …
But MaaS or Juju ?
And as far as I know, those projects are not that young, I remember seeing those names for the last years, this is not something brand new.
This lack of notoriety really doesn’t help in building a community around it.
Of course, this is way more specific than such a generic purpose project like Ubuntu itself but it should at least be as famous as tools from Hashicorp with such a backer like Canonical.
Unless you leverage Juju capabilities and making them facing a wider audience, it will be hard to aggregate a bigger community outside the Canonical ecosystem.
Why not writing plenty of articles/tutorials about Juju in places like Medium.com for example ?
I did a simple search and only found 1(!) article about deploying Openstack with MaaS/Juju … Whilere there are hundreds (if no more) articles about Ansible or Terraform.
I like the idea that Juju is more technically oriented and wishing to convince people by its own qualities but communication is key to a wider audience.
Regards.
It’s interesting isn’t it. Bit of a chicken and an egg problem. Notoriety brings traction with a community of developers, but traction with a developer community would bring notoriety.
I know Juju engineers and Product Managers are in and around this thread so really appreciate your 2 cents!
Would you mind dropping that link you found to deploying Openstack with MaaS/Juju?
Sure, here is the link : https://vanderspek-david.medium.com/deploy-openstack-ussuri-on-focal-with-maas-2-8-and-juju-9812a3f75a37
Your list of things that need to be changed/built, in order to make Juju a successful* project is great, Erik - thanks for that.
*My definition of success:
IMHO, community is not a commodity we can buy with a truck full of money and I agree with you that it depends a lot from spontaneous engagement, pro-activity and leadership from people outside Canonical. Juju is a great idea and decent implementation that has the potential to inspire people, but, to be brutally honest, I don’t have a YAML file recipe for success here and that’s where these meetups come into play.
I thought about setting up a call this week, inviting someone that has a true passion for the project and just having a chat with them. Let’s start small and decide in an open forum where we should go from there.
I second @Hybrid512 call for more exposure. The cool thing about Juju is that it creates a gigantic matrix of possibilities (app x substrate) that can be the base for 100’s of articles. I need to think how to organise that both internally and externally.
I think that many open-source projects are into this situation where they do not get as much engagement as they would wish for. There are some many different open-source projects that they just have to figure out ways to attract attention. I follow hackernews and I see everyday new mentions of amazing projects that I did not know they existed. And many of them are struggling to create a community.
Among the millions of potential users, even a niche project should be able to do well.
So, what’s going on with Juju?
The barrier of entry to start using Juju is too high. If I were to put myself in the shoes of a new user who just learned about the existence of Juju, has an idea that Juju can help with managing Internet services, what would I need to find?
nginx and upload the HTML files at the correct directory. If you were to improve on that, you would use configuration management, like Ansible, so that you automate a bit the process. But if you want to go one level ahead, you would use Juju with the appropriate charm for a static website and level up to application management.https with a Let’s Encrypt charm. Then, add multiple websites with a reverse proxy charm.The above set of three documents would make me have a genuine interest into trying out Juju. There are more things needed next, but that would be an adequate start for me.
We’ve definitely improved on this with Juju | The simplest way to deploy and maintain applications in the cloud
I second that : attract people gently so that they can easily understand what Juju is all about.
Believe me, when you’re not “inside”, this is not that clear what Juju is and what it does.
I would also use comparisons … “Operator” is a “Kubernetized bias” that is not understandable by newcomers.
You must explain what it is and I wouldn’t hesitate to make comparisons with established competitors … let’s just simplify and say that Juju is comparable to Terraform + Ansible … but with more embedded logic and automation.
You must explain how it compares to those well know tools and how it differs.
On the other side, most successful opensource projects, appart from the “marketing” side, were successful because they offered easy and clean solutions to complex problems.
Prometheus wiped out many other metrology competitors because of its simplicity and its robustness.
Writing an Ansible playbook is extremely easy (well … unless you want to do complicated stuff but for 99% of the use cases, it is fairly easy and efficient).
Terraform offered a “de facto” standard in ressource provisionning without vendor locking.
You see … you need to pinpoint the advantages of such a solution like Juju to explain why it is better for this job that another alternative.
Let’s say Openstack … there are many ways to deploy an Openstack cluster … why would you do it with Juju and not Kolla Ansible for example ?
(I have my idea but it should be explained in the sens of the end user and not based on technical details)
First, @simos, looks like that was your first post, welcome 
Second, damn, some very nice suggestions!
It’s a well known caveat that in order to have any hope of building a strong community you need to lower the bar to entry as far as you can, and then lower it some more. Making it easy for people to self-serve and self-start is super important.
What you’ve got there are three crackin’ places for Juju developers to start writing more tutorials .
@simonrichardson all of those tutorials are definitely an improvement, for sure, the more that come in the better of course. @simos there’s a nice tutorial on how to contribute a tutorial if you have time for any of your ideas 
I don’t know much Juju but if you come up with something I’d be very happy to kick the tyres and promote it with you?
It seems what’s missing, and I think this runs parallel to what @Hybrid512 is saying, is a proper ‘on-boarding’ / ‘on-ramp’ experience. One that takes users through a super simple journey, through the most basics examples, and explains the basics in industry standard terms and the benefits in comparison to ‘things you might have heard of’.
What would you folks say would need to be incorporated into that on-ramp for new users?
Hi all, this is a really interesting discussion and some really good points made from folks. I am a great advocate of Juju and appreciate many of its strengths. However I do feel it is way too biased and restrictive.
Without going into much details, it’s really difficult to persuade any power user to use Juju if he has even the slightest need for an extra configuration parameter, not already there in the charm. I myself prefer many to use other tools (ex. kolla-ansible to deploy Openstack) just because I have the flexibility, if I want, to override the “default” or prefabricated configuration of any service.
There are many other things that prevent users appreciate Juju, especially for small-scale scenarios, but most of them are covered from the points in previous posts.