Surely it does. Local hardware enablement and ease of use is the goal here. And I think most of the, dare I say traditional and uncontroversial, ML cases are well understood to benefit from this. The ML community should be able to join in and shape the outputs to better serve their use case.
I’m going back and reading the proposal with precision, and you’ll note Gordon doesn’t mention LLM or ML. He mentions frameworks and libraries..which in my head speaks to the ML development experience without having to name everything. He’s using AI consistently as an umbrella term for the workloads broadly. What this is is ultimately enablement and ease of use of local AI accelerator hardware.. local compute resources. The terminology about how this hardware is marketed continues to evolve. Gone are the days when we talk about these things as graphics processors… and vendors are definitely not talking about them as ML accelerators right now.
I can see how jumping on “AI is the future” bandwagon, pushed by various entities heavily invested into “AI” and not concerned with ethics in how they do business, by introducing “The Fedora AI Developer Desktop Initiative” can be considered by some people to be unethical, as it contributes to efforts to turn statements like this
into self-fulfilling prophecy, serving interests of said entities.
Considering that LLM output legality from copyright law perspective appears to be unclear so far, it makes sense to enforce strict marking policy to not contaminate the whole project. Right now, this change looks like consequence of undisclosed use of “AI powered” tools by contributor and not a herald of landslide adoption among kernel developers.
Another example of a statements some people may consider unethical, as in manufactured consensus.
Trained using what hardware? By what entity? On what dataset?
Good questions. Questions that have good answers in the ideal ethical future. Questions I want to give as call to actions to a community who see value in the technology and want better options. I definitely dont have those answers right now. But i am very confident that the more ethical answers to those questions can only come by standing up development platforms that make it easy to use local models and local hardware. The incentives driving the development of the big models are not going give us good answers to those questions.
I would love.. absolutely love.. to be able to get to a future where I could say as FPL these are our prefered local models because they address our shared cultural concerns based on the answers to these questions. These are the models we turn on by default in this dedicated AI output. But we have to get to that… if we can get that far.
The Council reviewed the Fedora AI Developer Desktop Initiative proposal with @gordonmessmer. Discussion covered naming concerns and hardware enablement, specifically the need to address the LTS kernel feedback in the Fedora Wiki proposal. Recognizing that the technical work is already underway and aiming to provide official guidance and legitimacy, the Council voted to approve the initiative. The approval is pending a short lazy consensus period ending on Friday, May 8th to accommodate absent Council members during the meeting.
Follow-up Items
Next Steps: Update the wiki proposal to address the LTS kernel feedback. Wait for the lazy consensus period to close on Friday. If fully approved, onboard the new initiative lead to the Council.
!agreed +6/0/-0 — The Fedora Council approves the AI Developer Desktop Initiative as a 12-month Initiative, led by @gordonmessmer and sponsored by @jspaleta. On the basis of our documented lazy consensus voting model, the decision will be ratified and final by Friday, 8 May in the ticket.
Relevant disclaimer - I am employed by AMD as part of their effort to get ROCm packages into Linux distros and keep them updated. That being said, my words and opinions are my own - they should not in any way be interpreted as “AMD said X”
Something that is also potentially relevant is background about me and my involvement in the “AI” space. I’ve been working on this stuff since before it was called AI, not as long as some others but I’ve watched things go from “that’s a cool academic toy nobody’s ever heard of” to the buzzword, debate and industry it has become. I started getting involved in the HW end of things because of how painful installing CUDA used to be and I wanted to see solutions that didn’t revolve around closed ecosystems that required a bunch of black box binaries to work (yes, I know firmware is closed but that’s more or less unavoidable at this time). I also felt that a good, open accelerator stack was required before a more open AI/ML stack could become realistic.
I’ve been avoiding this thread for a while, mostly because the proposal process appears to have skipped asking for input from existing ai-ml contributors but the discussion also seems to have become more of a philosophical debate about the direction of Fedora and the ethics of AI as a whole. That’s a very valid and important discussion I don’t want to take away from but I do want to address some of the proposal’s technical aspects.
From my POV as someone involved in getting heterogeneous compute (HC) and AI related packages into Fedora, this proposal doesn’t address any of our existing pain points beyond hardware enablement that can’t be done within current Fedora policies. As such, I have a hard time reading this proposal in its current form as much more than “we want to make CUDA more available in a Fedora adjacent deliverable but don’t want to phrase it that way”.
Don’t get me wrong, I have obvious biases but I’d be lying if I didn’t acknowledge the relevance of NVIDIA and CUDA in the HC ecosystem or why Fedora might want to target users who are looking for those things. I do, however, find this proposal a little frustrating. If the desire is to make NVIDIA drivers or CUDA easily available, that’s a valid thing to do but please don’t sell this effort as something significantly more than that.
The missing question I see is around how AI tooling is sourced and what we’re optimizing for. Is the idea to provide a platform for users to consume containers built by third parties relying on out-of-tree drivers or are we looking to provide a platform to run AI tooling that can be verified and rebuilt in the same way that Fedora has traditionally been?
This proposal seems to focus on kernelspace issues like drivers and implies that an LTS kernel would be better for all AI workloads. I would argue that is not quite the case for ROCm or Vulkan because those can and do rely on in-tree drivers but I do understand why this is the focus. Either way, this seems to imply that the goal is to provide extra drivers to users who want to use Fedora as a platform to build/run containers of things that are not or can not be built in Fedora.
The thing is, while your interpretation is correct, the underlying argumentation that has been presented is flawed. As you, I, and others have pointed out, the biggest problem is that we’re doing things to favor non-OSS stacks here, which is antithetical to what we are as a community and what we want as a project.
Putting aside my concerns about LLM technology, I do think other AI/ML technologies are interesting and would like to see enablement for them. But I’d rather not “grease” the wheels more for non-open stacks if we don’t have to, and instead actively promote and support open technology stacks for these purposes.
On AMD, we have ROCm, OpenCL, and Vulkan Compute. On Intel, we have oneAPI, OpenCL, and Vulkan. For NVIDIA, OpenCL and Vulkan Compute are both supported with the open source stack (NVK) and the proprietary stack (OpenRM).
I would vastly prefer us optimizing integration of these technologies over CUDA. We should be doing the “hard thing” and pushing people to open technologies. Because if we don’t do it, nobody else will.
I honestly wish I knew how to spend less time discussing NVIDIA. I think that enabling NVIDIA hardware is important, in as far as the status quo drives a lot of people toward other projects by virtue of the hardware they are using, and the loss of their participation hurts the project. But I also think that this is the smallest problem to solve, and that is why I predict that it will be completed before any other work.
To be clear: I think that akmods and dkms are bad systems. They are fundamentally unreliable and insecure. They have papered over a problem, and allowed Fedora to ignore that problem rather than solving it. Developers should be able to ship software that enables hardware. Most of the individual pieces exist! Pesign can be used to sign modules. The Fedora Message Bus can notify developers that a new kernel has been built. The infrastructure exists to coordinate builds. We need some improvements to support dependency handling around kernel modules and probably some other work… I’ve been talking to Neal about work he plans to do to improve kernel module handling, and I’m very interested in helping him. I believe this is not an unsolvable problem. Enabling NVIDIA isn’t really the problem, it’s just an example of the problem. The problem is that it’s difficult for the developers of kernel-mode software to target Fedora.
But that’s just the first problem. The interesting and difficult and very important work will take longer. As I said above, developers are also telling us that it’s hard to use Fedora or target Fedora, independent of NVIDIA. There’s an audience of application developers that we’re not serving well, and I see evidence of that everywhere. In our meeting this morning, we discussed the need to contact maintainers and coordinate updates of dependencies, and I think that’s backward. Fedora’s structure works well for building a collection of mature components that move in unison.
But the world is changing, and the technology emerging now is changing it faster than we are prepared to deal with. Security threats are going to continue to emerge faster than we have seen in the past, and security *exploits* are going to emerge faster than we’ve seen in the past.
I expect that because I am saying we need to enable updates to move faster that someone will infer that I am saying we should replace maintainers with AI and I want to very explicitly say that I am not saying that. But I think there’s a whole lot of work that we are doing manually even though we have (deterministic) automated tooling to do now, and we’re just not using it consistently. I think that makes it much harder to target Fedora than it could be, and additionally, I am very concerned about our security posture in a world where our adversaries are assisted by “AI”.
Better tools for developers are critical to solving those problems. It should be easier to target Fedora as a platform. It should be easier to build software on Fedora systems. Some of the people who want to develop and deliver software on Fedora will want to use assistants, and I think we should enable that. It should be easier and faster for Fedora maintainers to ship security patches. And I think all of those are actually the same problem.
That true. I don’t love that bit. I definitely don’t want to change the project’s values to bring non-Free software into the project.
I see the remix as the least bad option today to create something that will run applications that have already been developed and give some users and developers an on-ramp into Fedora. I would like for the remix to exist, with the specific goal of upstreaming into Fedora things that can be upstreamed into Fedora. Remixes and forks exist today which do not have the explicit goal of improving Fedora, and I think we’re missing out as a result.
I also think the Remix is a good way for Fedora to demonstrate good engineering practices for people who necessarily operate outside of Fedora. I wouldn’t advocate for Fedora building and signing … I don’t know… WiFi drivers that independent developers write. But at the same time, Linux was created by independent developers, and I think we should not discourage such development. I see some pipelines in use that don’t have strong signing key controls, and I think demonstrating better practices is better for everyone that expecting people to just figure it out on their own. I want to support people developing software on Fedora and for Fedora, even before that software is ready to include in Fedora.
I also want to encourage open technology, but in order to do that, we have to bring people close enough to hear us when we talk about those systems.
In other words, I want to encourage developers to use ROCm or Vulkan or OpenCL, but we have only a little influence over developers using Fedora, and none at all over developers using other platforms.
As far as I can tell, the idea that AI is an ethical problem is a judgement on an application, but we’re not building applications, we’re building a platform.
In my previous jobs, my coworkers built AI systems for incident response, ingesting system metrics and automating remediation. They built AI systems for log analysis and security monitoring. As I said elsewhere, lots of assistive technology is AI or is developed with AI: voice recognition, computer vision, input assistance. “AI” has lots of legitimate, ethically good uses.
Computers are machines that perform actions on our behalf. Some of those actions are written in code, but they can also be the result of statistical analysis and repetition.
I can only speak for myself, but believe there is a future in machine learning as a platform, and I don’t think the platform has any inherent, significant ethical problems.
Building better development tools will make it easier to develop and run applications that do have ethical problems. That’s true. I’m not sure what to do about that. We can do nothing and accept that Fedora is kind of difficult to target. But that just means that those developers will use a different platform and we’ll have a platform that’s hard to target. I don’t think that’s a much better world.
I don’t have all the answer here, but I don’t want people to feel like their concerns are being dismissed without consideration. I care what people think, and I want to talk about how the things we build reflect our values. And while we do that, I would like to address some of the problems that make it difficult to target Fedora as a platform.
Gordon, I get the “we’re building a platform, not applications” argument, but I don’t fully buy it. Fedora has never treated platform choices as value-neutral. We don’t ship proprietary codecs by default for a reason. The same thinking should apply to how we approach AI enablement. What we make easy is a statement about what we value.
And the idea that we bring people in through the proprietary path and then nudge them toward open alternatives… in my experience that just doesn’t play out. The proprietary path becomes the default, the open one stays “nice to have,” and nobody gets around to pushing it. I do totally support what @ngompa said.. if we don’t do the hard thing here, nobody will. ROCm has in-tree drivers. Vulkan Compute and OpenCL work across vendors. Tim’s question about whether this is essentially “make CUDA easier on Fedora” deserves a straight answer.
@jspaleta I have to disagree with you there on the ‘ideal ethical future’ . When you say you don’t have answers yet to “trained by whom, on what.” There are already real options out there. Granite models are Apache 2.0 with published data provenance. StarCoder2 was trained on permissively-licensed code with opt-out for developers. RedPajama and DCLM are building fully transparent training datasets. These aren’t future hypotheticals, they’re shipping today. If this initiative is serious, we should be defining what models meet our standards and recommending them, not waiting for a perfect future that may never arrive.
To be clear, I’m not directly against the initiative. Running models locally on your own hardware is better than routing everything through proprietary APIs, full stop. But if the first concrete deliverable is CUDA enablement via a remix and everything else is aspirational, then we’re reinforcing the exact dynamic we say we want to change.
I’d rather see us lead with the open stack… ROCm, Vulkan Compute as first-class targets, a curated set of models with real provenance, tooling tested against open compute first and treat the proprietary enablement as the accommodation, not the starting point.
I can’t believe what I’m reading in this thread. I’ve been out of the Fedora loop for a while. But I didn’t see this coming. @jspaleta From what I can see, you’re busy erasing every trace of the Fedora community. “Hard conversations”, are you my boss, and are you going to fire me? This is supposed to be a community; a lot of people here volunteer their time. If it’s not fun, I’m taking my time elsewhere.
@gordonmessmer You keep making claims that aren’t true. Fedora isn’t difficult to use or work with. I’ve never received such overwhelming feedback, especially not at conferences. None of the solutions you propose would solve that problem anyway.
But then again, who cares about ethics, politics, and philosophy? This movement has been built precisely on those three things. But who the hell cares? We need to build, build, deliver, and roll out. Fast, right now. If corporations are driving you crazy, at least have the decency to acknowledge and respect those who stand up for what they believe in. When the world comes crashing down, you’ll throw your hands up in horror and have the nerve to say, “We had no other choice!” But that’s not true. There was a choice, and some people fought for it. You didn’t.
The fact that I have to use an anonymous account so I don’t lose my job or get into trouble is really sad. I really miss the people who cared about Fedora, the community, and the project.
Yes, platform can help with some aspects, and it is better than nothing, but the dataset problem, which is fundamental to LLMs, is impossible to solve with a proper training and inference platform alone.
Even most permissive of licenses include some conditions, and answers to questions on applicability of such conditions to LLM weights and output lie in realms of philosophy, religion and law. Some people may consider opt-out excuse to be lame and insufficient.
In a way some people may consider helpful in pushing unethical applications due to bandwagon effect, regardless of technical aspects. I am not saying that this is the only correct or ethical perspective, but it exists and may be popular.
@tflink and @dmellado point at deliverables. Even Debian has introduced non-free-firmaware component enabled by default, hardware support makes sense, but AI is a very broard term. This initiative appears to be, first and foremost, targeting LLMs, despite its broad title. What about decision trees, symbolic AI and whatever has been invented the last few decades? Fedora Scientific Lab | The Fedora Project already exists for numerical computation workloads.
To reinforce this point, one reason that NVIDIA became an outlier in the first place is because we exerted pressure and reinforced our ethical and ideological stance here that non-free/closed technologies were unwanted. We have compromised in some respects (e.g. firmware), but in most respects we historically haven’t. That made AMD eventually capitulate and retire fglrx for amdgpu. And now AMDVLK has been replaced with the openly developed RADV. These are wins that you don’t get unless you hold firm.
I use Fedora because we do stuff like that to help drive the future of open technologies and promote Free Software. I use and develop Fedora KDE because I believe firmly that we have to be the change we want to see, and that means working through hard things around multimedia, working through hard things around usability, and working through hard things around hardware support.
We have intentionally kept the NVIDIA proprietary stack at arm’s length on purpose. Even the existing AI/ML SIG (which was not engaged or consulted on for any of this proposal) threads this needle at least reasonably well by focusing on stacks that leverage open technologies and actively working in upstream projects to enable them.
I respect that @gordonmessmer has a particular view of problems he wants to solve. We even had a productive in-person conversation about it early last week and there’s even some alignment on things to fix. That being said…
It’s pretty easy, actually. Instead of talking about NVIDIA, talk about what they use NVIDIA for and work with people to close the gaps there. The Linux market is majority AMD/Intel, not NVIDIA for GPUs. The client-side “AI” market is almost 40% non-NVIDIA between Apple Silicon and Intel/AMD laptops. The cost of NVIDIA GPUs has skyrocketed too, making non-NVIDIA hardware more attractive (even in DCs), provided the software enablement is present.
Most AI/ML projects do not interface with CUDA directly, they use abstractions like libtorch, litert, blas, and so many other things that allow mathematics to be represented more cleanly. Enable those to use open technologies and promote the fact you’re making things more accessible by using more accessible hardware.
Honestly, this is more mixed in my experience. It entirely depends on the audience, the technologies, and their awareness. At least for classical numerical work, Fedora serves that audience pretty well and has for a very long time. Scientific research is an area we’ve done reasonably okay in. Commercial ML has been weaker because for a long time it was centered on TensorFlow, but these days it’s on libtorch through PyTorch and other more accessible technologies. Furthermore, Fedora’s AI/ML SIG (which absorbed the existing high-performance computing folks too), has not actively marketed their work. That results in a perception that those particular technologies aren’t easy to use in Fedora. On a lark, I actually tried out ollama from the repositories with the Gemma4 model on my Framework 16, and it just worked. Other open source models worked as well. So we have the basic pieces already, we just need to promote them in the way we want to push the world to look at things.
The audiences I tend to talk to actually say Fedora is the easiest platform for them to get started on. Game development, multimedia production, software development, and other similarly advanced tasks are extremely well-supported in Fedora. Enterprise software development in Fedora has gotten worse as Red Hat has slowly pulled out of Fedora Java and .NET still lacks real guidance on how to use it, but all the rest of the software development spaces are reasonably healthy.
But, I am extremely unhappy with the Fedora Council essentially ignoring the community discussion that indicated that at the minimum this was probably not okay to greenlight as-is. I’m especially disappointed at how we’re being told that as our opinions and interests in the project as highly engaged contributors do not matter.
Fedora as a community project does not function if we all decide to pack up and leave. There are even more disastrous outcomes that can occur if people continue to feel steamrolled.
Communities have hard conversations all the time. I certainly remember several of them in the first few years of this project when I was an external contributor.
The hardest community conversation in my life.. was when I was on the board for my curling club during Covid back in Alaska and we had to have a discussion about closing up the building during Covid. And every single one of us in that room, who was empowered to make the decision, we didn’t know if the curling club would be able to actually financially survive closing down for what ended up being a year and half. The easiest thing we could have done in the moment was to just tell people, use your own judgement, we aren’t going to cut the season short, we are still going to have a big year end event… the event that basically pays for the operation of the building.
That was absolutely the hardest conversations in my life..so far. People I really cared about, left that community because of the decision we made as club leadership. It was a very hard conversation. Gut wrenching. Communities have hard conversations about hard topics.
I agree. I would prefer to lead with open stacks. I believe the initiative anticipates that by saying the nvidia enablement work exposed to users will need to exist as a remix that makes use of the base image that is also an output of this initiative. It’s also the thing that is most likely to evaporate because the open source drivers make the necessity of that remix irrelevant and we can stop producing it and the main output of this is still a viable developer oriented output.
The base image has to come before the remix that uses it. The first end user consumable output of this is the base image.
So let’s have that. There is no reason this needs to be made into an initiative right /now/. Let’s have the remix exist; form a SIG with the appropriate communication channels. Build up a community around it before making it an initiative. If it turns out to be nice, popular, sustaining, and not a drag on community resources and more importantly community togetherness then an initiative feels appropriate if desired, as the goals have likely already been achieved at that point.
This feels like a huge amount of uncertainty, disregard for well-established community members and their concerns, and a train that must leave the station for something that in reality is just that. A remix. That could’ve come into existence without any of that and then after existing for a while has a much better chance of convincing us that ‘hey yea this is feasible and it is a good thing’.
The above is aside from all the technical limitations I see in the ideas that have been floated here.
Let’s look at the 2028 futures I’m able to see again. The future when an initiative started now-ish could hand off to a working group responsible for an edition that the initial base image may grow into.
In the best version of that future that I can see…
the nova kernel drivers are well established and vulkan compute becomes the defacto standard for accessing local hardware and somehow magically we don’t even need cuda. We can just do all of it in the base image. Fantastic future from a technical perspective. Clean.
In that future, I still see a need to promote an AI developer desktop output. I still think its a strategic output. We just avoid the policy complexity of having to deal with out of tree open source kernel drivers and proprietary cuda userspace to get maximum hardware enablement.
I don’t see the strategic need for the base output changing. And there lies the disagreement that is surfacing the hardest conversations. Even if there are technical solves for the hardware enablement in that time frame, this project community is still left with needing to have the conversation about whether to build and promote an output for AI developers is strategic. what I see people reacting to most strongly in the back half of this thread now is that question and my answer to it.
Even if we choose to delay this as a council level inititive until after the nova drivers are here, because the nova driver availability makes the technical work less burdensome, the larger conversation about whether its strategic to promote the output for the stated use cases is still there.
I feel it would be inappropriate for me to not step in front of that conversation and tell you what I think about the strategic importance of an output aimed at developers. I believe that the base image that comes out of this work needs to be an edition with its own working group in the 2028 timeframe.
Why are developers claiming that it’s hard to use Fedora or target Fedora? If that’s independent of NVIDIA, why does it seem like enabling NVIDIA hardware is the first thing that’s being targeted? Which developers are complaining? Is it just AI-related stuff?
Isn’t the problem of coordinating updates part of the hard problem that distros solve? I don’t understand how this relates to a new spin or AI or anything like that.
I don’t understand what all of that has to do with the desktop objective. What am I missing or misunderstanding?
I’m not assuming bad faith from anyone but in the interest of being clear, I am going to be a little less reserved in my choice of words.
This proposal feels a bit like an “underpants gnome” style sales pitch which went:
steal underpants
???
profit
However, instead of an absurd fictional situation it’s more like
add out-of-tree drivers and maybe proprietary middleware
???
profit
I want to know what’s in the “???” part
There is a LOT of work between the question of accelerators and a working AI/ML setup and I feel like this isn’t even being acknowledged in the proposal. What exactly is in this new deliverable? Other than the out-of-tree kernel modules and maybe an LTS kernel, what does it do that existing spins/remixes don’t?
Is the intent just to provide a mechanism for running containers that has out-of-tree modules pre-installed?
Is there an implied longer-term proposal to have a Fedora-adjacent deliverable that provides a Fedora-maintained AI stack that otherwise adheres to the 4 Fs?
If the point of this proposal is to provide a method for launching containers that need extra kernel bits, I don’t understand why the separate desktop deliverable is required here. Wouldn’t providing or pointing to a repo containing a kernel with the desired out-of-tree modules work almost as well with a lot less work?
If the point is more than just providing a method for launching containers, how would Fedora’s existing packages work? If CUDA userspace parts are involved, would CUDA binaries live in a separate repo as well? Would existing Fedora packages have to find a way to build against CUDA in a way that wouldn’t require it at build time? Would all of the AI-related packages in Fedora be forked and built outside of Fedora with the other bits that aren’t quite able to be included in Fedora right now?
What is the end goal here and how does making a new desktop spin/remix help?
edit: missing word to make sentence more grammatically correct
I thought I gave it a straight answer, but I’ll try again.
The work that I have described is not intended to be an endorsement of anything. All of it is intended to identify rough edges that should be smoothed out, and in that way, it is all a criticism of something and I’m trying to not fingers at too many people too directly.
I really dislike akmods and dkms. They are bad systems. They break user systems frequently, and they are bad for our reputation. The NVIDIA OpenRM module is merely a useful example of an out of tree module that could be built by a third party. I would like to use it to smooth out the rough edges of the support we provide for third party kmods and demonstrate a better process. I’m not endorsing NVIDIA so much as I’m criticizing akmods and dkms.
(Contrary-wise, I do find it disappointing that NVIDIA gave us a win by publishing an open driver and we did nothing with that.)
Fedora/CentOS/RHEL provide some really cool infrastructure that I don’t see anyone using. Fedora’s Message Bus should support coordination of kmod builds with new kernels. CentOS developers offered to support third party kmod builds to ensure that supported interfaces didn’t unintentionally break builds, and I think the Integration SIG provides some of the implementation needed to do that. But we have years of evidence that suggests that providing the infrastructure alone is not enough, because these things aren’t being adopted where they’re needed. Developers need a demonstration. They need something that works that they can fork and adapt incrementally to their needs.
Fedora policies permit Remixes, but some of what we see is forks instead. Some of those forks are pretty vocally critical of Fedora. I have heard Red Hat leadership wonder why Fedora doesn’t have Atomic configs that interested third parties can fork and build. I thought “well that’s weird, we have that right?” But when I tried to build an image of my own I found a bunch of stuff that needed to be fixed to make that usable for third party developers.
And I find that’s true of a lot of Fedora tooling. It’s great for Fedora’s use to build a distribution. It’s less useful for third party developers. And if we want to grow, the most useful feedback we can get comes from the people who are having a hard time using what we have.
If my answers still seem indirect, try to understand the proposal from this point of view: I am trying to identify the places that Fedora is hard to use. I am trying to smooth rough edges. I am trying to demonstrate that Fedora is usable by third parties, by using it from a third party position. I am trying to demonstrate that a Remix can be a workspace to prove concepts with the intent to upstream improvements. I am trying to demonstrate better processes where I see bad implementations. I would prefer to demonstrate the way that I wish things were done and prove that they can be done that way than to merely speculate about things that could be improved.