Just to move slightly sideways, how about alook at the structure of this project. There is a clear suspicion that a select few are running the project ultimately for their own financial benefit. There is also suspicion that, because they are unexplained, changes are to further that end. (PS I don’t subscribe to those theories, I am trying to summarise what I observe).
So how about our strucure? Who is in charge? Who knows!
I only have experiennce with structure of one other project, namely Kodi. Kodi has at the top a Board, elected by team members.
The Team is made up of a mixture of devlopers and others. This is where the day to day control rests. The non devs on the Team might be retired devs (no time to code the project but still interested and able to guide and mentor newer devs), forum mods who have been around a while and who’s views are respected, importantly they are usually in touch with users.
With the team members drawn from not just devs, project direction is a lot more transparent, and better explained. The decision making is not perceived to be made by an elite few, whose motives may be unknown.
I am not saying that this model is ideal, or would work in a smaller project like HA. Just chucking ideas around.
I say again, this is not an attack on devs. It is about public perception, public accountability and ultimately spreading the workload.
Discuss, and maybe split the thread if discussion goes anywhere.
@SeanM I don’t disagree with you on this and don’t think I ever stated it should be hard, my concern has always been that moving in this direction removes features for long term or advanced users. If “the old ways” of using YAML can be left to coexist alongside integrations this would keep the large majority of people happy. Not everyone will, or can be pleased, but this would certainly help.
Good point, this is a something I have not considered.
Yes, could do things from the GUI, not have to do things from the GUI. I’ve watched the SOTU videos and have revisited them a number of times.
I’m sure the Devs have a medium to long term roadmap in place and part of that I’m sure would be a discussions around HA being a viable business (or not).
Let me be clear - I pay for NabuCasa on 1 of 3 instances I maintain, so I am not anti revenue stream for people working long hours on the project, server costs etc, but would like some transparency on what is being given more weight in development process. If the goal is to make HA an attractive package for business purposes, be honest about that. If that is not the goal, then state that.
Changes to architecture are ran though the https://github.com/home-assistant/architecture repo and regularly discussed by all devs when proposed. Ideas are passed around, weighing pros/cons and ultimately core devs (those who have worked on the project quite a bit) either approve or close issues/PRs related to architecture. No backroom dealings to my knowledge, just a bunch of developers who have invested a lot of time into something they enjoy, wanting to create something that anyone can use and scales from newbie to power users.
As a frontend dev, I don’t get into the weeds with architecture all that much, but I do use HA (for 4 years now) and have set it up for many family members as well in that time. I super pumped about the direction the project is headed (my dad setup his first integration on his own the other day and he was stoked to tell me about it) and would be absolutely dumb-founded to learn that anyone, and I mean anyone, at the core of HA didn’t feel that this is just a fun project to work.
You look at all the Nabu Casa employees, they are all just devs who enjoyed it so much that they pored in countless hours into something that would profit them nothing (beyond making their own smart homes better which is my main motivation as well), so much so that they their love was noticed by @balloob as someone who would be great for a company focused primarily on making HA the best it can be. The idea that they would go back on the core principals that drove them to contribute to the project in the first place, to get “rich”, just seems silly and childish to consider.
In the end, I’m one guy who is here to have fun making shit work with my home and I think that is really what everyone else is trying to do too. Drama like all of this, really just derails any and all motivation I have though. I just want to code cool shit, man.
Why only devs participate in architecture decisions? Perhaps if the potential changes are posted to the blog and the forum so the whole community can have a say?
Why will no developer answer the often asked question: why does going to gui integration require using json instead of yaml? I believe that anything you can express in json can be expressed in yaml, so why change?
I was tagged for response, so let me respond to this about the architecture repo. It sounds nice but in my experience it just does not work like that. Many architecture discussions are stale. There is no prioritization or formal process for getting changes through. The only items being closed with a resolution are the ones where everybody agrees or where balloob has a strong opinion.
I found the architecture discussions fruitless because I was often given “clever” opposing responses that showed that my carefully drafted input had only been skimmed.
It wore me down to spend hours on an architecture issue and see that nobody cared. It is what ultimately caused me to stop as a top contributor. I was no longer having fun.
I do know of at least one other very great developer that has left in frustration but even though it is pretty bad for a project to lose an experienced developer, the project surely can go on without us. Many other great people and great developers have come along and I think the project is generally going in a great direction. However, I wanted to add my story to show that the structure of the project indeed has a cost.
Thank you @amelchio for your input. Very interesting.
I have decided to subscribe to the architecture issues and post any that I find interesting/significant/important to the forum. That way more people will become aware of them.
Unfortunately not being a programmer, I will not always know the significance or importance, but it is a start.
In doing so, I found an architecture issue that interested me, so that was a bonus
Thanks for the tagging (sarcasm), which I generally btw, do not appreciate and is kinda fraud upon (especially in mass tagging).
Let be make this very clear from my perspective: I’m just having lots of fun doing this. Even though I’m now working for Nabu Casa, it just enables me to invest more hours into the project. From my perspective, I’m still a contributor enjoying working on the project.
I have my own opinions, and make up my own mind. The project still works of a contribution model where anybody can contribute a suggestion or change.
So instead of wasting my time on all kinds of weird theories on Nabu Casa making decisions on the project future, or whoever, I’m going back to what matters, contributing to this project.
Edit:
Just wanted to add to this, as this is spun off by the decision made in the future of YAML blog post:
That is the PR for the ADR, signed off by a bunch of people (like a lot). Not everybody involved has approved the PR (being off-line, and other reasons). Just wanting to show this isn’t a simple change that was dropped without discussion or consulting others.
Thank you I did include bram as a major contributor to the frontend code. Ultimately there is a limit of 10 people I can tag in a post do I had cut some of the @'s.
I didn’t know bram was an employee of nabu casa. It seems that the only way to know these things is???
Converting from and to yaml comes with a performance penalty. Not huge (depending on the machine obviously though), but it’s present.
The conversion will re-format / re-order the data (and remove comments). Have a look at the UI-generated automations (the yaml where they are stored). A tidy, structured, manually created, automation will become what you see there. People would complain with “Why is my yaml so messed up now? And where did my comments go?”.
There’s no benefit in storing data in a human readable format if it’s not meant for humans to interact with.
That is a funny way to look at it. The ADR was open to public discussion for two hours before it was merged. It completely ignores Strategy for config methods · Issue #143 · home-assistant/architecture · GitHub which had ongoing discussion and where balloob once stated “Our goal for every integration is to have a config entry […], configurable via the UI, overridable via YAML.”
That ADR has been created with the core contributors in the week before that. It was shared with them and opened up for discussion. You are part of that same group @amelchio. You haven’t responded on the discussions…
I assume there was a typo or language issue there.
I know about tagging being frowned upon, but I thought a discussion about project structure would be highly relevant to you and the others tagged in. I usually only do it if really necessary to draw someone’s attention to a particular issue.
I was not espousing weird theories on NC. Others are, and their ideas need to be dispelled because I am with you on believing those theories are weird. But if you want to dispel those ugly thoughts, my proposal is simply that a bit of structure and accountability might help in stopping people thank those silly things.
Clearly there are people who think that their choices are being taken away by a few at the ‘top of the chain’ - some sort of structure around strategic decision making might help you guys.
Even appoint a community liason person who is not so much a coder, but can explain these things to the users without distracting dev time. Like answering the simple question about “why json as opposed to yaml”. Asking that question is not about weird theories, it is a genuine question.
Believe it or not @frenck I am on your side. I want to help getting the project on an even keel so as to stop the silly arguments and help communication and opennesss. Coders are not always the best communicators. If I was busy coding, I wouldn’t be wanting to answer repetitive silly questions, get someone else to do it.
Probably, but I didn’t rememebr that particular post nd didn’t know where to find out.
And now I do.
Thank you very much, although I must say that the first point pre-supposes that json is needed in the equation at all. Maybe it is easier for coders to work in json than yaml. These are things that I, as a non dev, don’t know. Thank you again.
Bed time now. Of course when I leave the room the kitchen media player will turn off so as not to keep the household awake all night. When I shower the temp and humidity will rise in the bathroom, which (when I install a fan) will trigger certain automations to clear the air). All thanks to the devs of this wonderful software. Cheers.
yaml always has to be converted for code to work with the data. And json as well. But json is much closer to the native data type that Python is using. Think of it this way: yaml is json with applied formatting. The formatting is just eye candy that comes at a price.
Don’t know and don’t care, honestly. They are both awful and things I try to avoid as much as possible 
That is the PR for the ADR, signed off by a bunch of people (like a lot). Not everybody involved has approved the PR (being off-line, and other reasons). Just wanting to show this isn’t a simple change that was dropped without discussion or consulting others.