As the board announced earlier today , I will be stepping down from the Executive Director role this week. It’s been an interesting four months. If you haven’t been following my work with the Foundation during that period, you can peruse the weekly Foundation Reports starting from May 3rd. You can also hear me in a few places at GUADEC 2025: the Day 1 Panel Discussion (where I was extremely sick), my Day 3 keynote , and the AGM from Day 3 .

As Allan mentions in his post, he’s taken over the role of board President. This means he will also be taking over as acting Executive Director when I step down, as per GNOME Foundation bylaws , and picking up where I left off. I’m enthusiastic about this transition. I have enjoyed working closely with Allan over the past four months and, with him at the helm, my only disappointment is that I won’t get to continue working closely with him.

It’s not only Allan, of course. In a few short months I’ve found it remarkable how hardworking the entire GNOME community is. You folks accomplish so much in such short spans of time, with limited resources. But even more surprising to me was just how warm and welcoming all the contributors are. A lot of folks have built a real home here: not just a professional network, but an international village. Language, cultural, and economic barriers are broken down to make GNOME such an inviting project and I’m honoured to have served GNOME as ED, even if only for a brief period.

With that in mind, I would like to thank a number of hackers I’ve had the good fortune of speaking to over the past four months.

First, those folks with non-development roles. Maria, Pietro, and other volunteer conference organizers. The unnamed contractors who balance the Foundation’s books, clear invoices, provide legal advice, consult, and run trainings. Karen, Deb, Loren, Amy, Stefano, Sumana, Michael D, and others who are long-time GNOME supporters and mentors. Andrea, who still contributes an inordinate amount of volunteer time to GNOME infrastructure and the elections process. Emmanuele, Alice, Michael C, Jordan, Chris, Brage, Sri, and others who quietly moderate GNOME’s social spaces to keep them safe. GNOME owes a great deal to all these folks. Their contributions largely go unnoticed. Everything that just magically works? That’s because someone is putting in a lot of time and effort to keep it that way.

Second, the Design Team. I’ve had so many wonderful interactions with Jakub, Allan, Tobias, Sam H, Jamie, and Kramo that I’ve lost count. I’m in awe of how quickly you folks work and I’m grateful for every opportunity I’ve had to work with you, big or small. Jamie and Kramo, for your help outside the Design Team, in particular: thank you for keeping me honest, calling me out on my shit, and never giving up on me even if I say or do something stupid. It means a lot.

Thank you to GNOME’s partners, Advisory Board reps, and other folks who the community may not see on a regular basis. Jehan, thank you for everything you do for GIMP. Scott, it was a pleasure meeting you at GUADEC and learning more about SUSE! Jef, thank you for your continued advice and guidance. Jeremy and Michael: I really enjoyed our AdBoard day and I hope GNOME gets even more vertically integrated with upstreams like Debian and LibreOffice. Aaron, Mauro, Marco, and Jon: I’m optimistic you folks can bring Ubuntu development and core GNOME development closer together, and I’m grateful for all the time you’ve given me toward that goal. Matt, Alejandro, and Ousama: I genuinely believe the way the Linux desktop wins is by shipping pre-installed to your customers at Framework and Slimbook. Mirko and Tara: as a user, I’m grateful for STF continuing to finance the underpinnings of GNOME’s infrastructure, and I look forward to seeing what else STA can do. Aleix, Joseph, and Paul: KDE is lucky to have you folks and GNOME is lucky to have you as friends. Paul especially, thank you for all your fundraising advice based on your experience with KDE’s campaigns. Robin, Thib, and Jim, thank you for giving us a federated Slack alternative! I feel many people don’t appreciate how relentless you are in improving your product. Mila, Spot, Henri, Hannah, Chad, Rin, Esra’a, and others: thanks for being on our team, even if you work for proprietary software companies.

And, of course, the text hackers. Thanks to Alice, Jordan, Emmanuele, Martin, Neils, Adrian, Jeff, Alexandre, Georges, Hari Rana, Ignacy, Mazhar, Aaditya, Adrien, swick, Florian, Sophie, Aryan, Matthias C, Matthias K, Pablo, Philip W, Philip C, Dan, Cassidy, Julian, Federico, Carlos, Felix, Adam, Pan, Kolja, and so many others for your conversations not just about GNOME development but the entire process and ecosystem around it. My conversations with you guided my entire time as ED and I hope you continue to provide the board with the same strong feedback you’ve given me. Joseph G and Andy, I’m sorry we never managed to sync up!

Last but not least, I’d like to thank the previous EDs over the past four years. Holly and Richard both had incredibly difficult situations to deal with. Richard, I’m very lucky to have met you in person and to get a real hug from you in June when I was struggling. I’ve said it before, but GNOME (and the board, in particular) is extremely lucky to have you as a friend and advisor.

I have undoubtedly forgotten people. Thankfully, you can complain to me directly. If you like the work I’ve done at the Foundation, you can also speak to me about other roles in the space. I would love to continue working within the wider Free Software ecosystem and especially on the Linux desktop.

I will be fully off-grid for two weeks mid-September so I can meditate a 10-Day “self course.” (Our proper 10-Day Vipassana course was cancelled due to the ongoing Nova Scotia wildfires.) But I’m back to the real world after that.

I’ll be around on Matrix and Discourse as a GNOME Foundation Member. I’m on Mastodon. I have another blog . My name was a Googlewhack once. You can also reach me using the standard flastname@gnome.org email format. You can find me. My door is always open.

Steven Deobald has been in the post of GNOME Foundation Executive Director for the past four months, during which time he has made major contributions to both the Foundation and the wider GNOME project. Sadly, Steven will be leaving the Foundation this week. The Foundation Board is extremely grateful to Steven and wish him the very best for his future endeavors.

The Executive Director role is extremely diverse and it is hard to list all of Steven’s contributions since he has been in post. However, particular highlights include:

• energetic engagement with the GNOME community, including weekly updates focused on the Foundation’s support of GNOME development, and attention to topics of importance to our contributors, such as Pride Month and Disability
  Pride
• the creation of a new donations platform, which included both a new website, detailed evaluation of payment processors, and a strategy for distributing donations to GNOME development
• a focus on partner outreach, including attending UN Open Source Week, adding postmarketOS to our Advisory board, and the creation of a new Advisory Board Matrix channel, alongside many conversations with partner organisations
• internal policy and documentation work, particularly around spending and finances
• the addition of new tooling to augment policies and documentation, such as an internal Foundation Handbook and vault.gnome.org
• assistance with the board, including recruiting a new treasurer and vice-treasurer

We are extremely grateful to Steven for all this and more. Despite these many positive achievements, Steven and the board have come to the conclusion that Steven is not the right fit for the Executive Director role at this time. We are therefore bidding Steven a fond farewell.

I know that some members of the GNOME community will be disappointed by this decision. I can assure everyone that it wasn’t one that we took lightly, and had to consider from different perspectives.

The good news is that Steven has left the Foundation with a strong platform on which to build, and we have an energetic and engaged board which is already working to fill in the gaps left by his departure. I’m confident that the Foundation can continue on the positive trajectory started by Steven, with a strong community-based executive taking the reins.

To this end, the board held its regular annual meeting this week, and appointed new directors to key positions. I’ve taken over the president’s role from Rob McQueen, who has now joined Arun Raghavan as one of two Vice-Presidents. The Executive Committee has been expanded with the inclusion of Arun and Maria Majadas (who is our new Chair). We have also bolstered the Finance Committee , and are looking to create new groups for fundraising and communications.

Steven has been very helpful in working on a smooth transition, and our staff are continuing to work as normal, so Foundation operations won’t be affected by these management changes. In the near future we’ll be pushing forward with the fundraising plans that Steven has set out, and are hopeful about being able to provide more financial support for the GNOME project as a result. If you want to help us with that, please get in touch.

Should you have any questions or concerns, please feel free to reach out to president@gnome.org .

On behalf of the GNOME Foundation Board of Directors,

– Allan

• Up early, mail chew, tech planning call, sync with Naomi & Anna, more admin.

Artificial intelligence isn’t just for tech giants anymore. In 2025, small businesses across every industry are leveraging AI to streamline operations, enhance customer experiences, and boost profitability. If you’re wondering how to implement AI in your small business, this comprehensive guide will walk you through every step of the process.

Why Small Business AI Implementation Matters in 2025

The AI revolution has reached a tipping point. According to recent studies, 73% of small businesses that have implemented AI report increased efficiency, while 67% see improved customer satisfaction within the first six months. More importantly, businesses using AI solutions show an average 15% increase in revenue growth compared to their non-AI counterparts.

The competitive advantage is clear: Early AI adopters in the small business space are capturing market share while their competitors struggle with manual processes and outdated systems.

Step 1: Identify AI Opportunities in Your Business

Before diving into artificial intelligence consulting or purchasing AI tools, you need to identify where AI can make the biggest impact in your operations.

Common AI Implementation Areas for Small Businesses:

Customer Service & Support

• Chatbots for 24/7 customer inquiries
• Automated ticket routing and prioritization
• Sentiment analysis for customer feedback

Sales & Marketing

• Lead scoring and qualification
• Personalized email marketing campaigns
• Predictive analytics for customer behavior

Operations & Inventory

• Demand forecasting and inventory optimization
• Automated scheduling and resource allocation
• Quality control through computer vision

Financial Management

• Automated bookkeeping and expense categorization
• Fraud detection and risk assessment
• Cash flow prediction and budgeting

Action Item: Conduct an AI Readiness Assessment

Create a simple spreadsheet listing your current business processes. For each process, ask:

1. Is this task repetitive and rule-based?
2. Do we have sufficient data to train an AI system?
3. Would automation here save significant time or money?
4. Could AI improve accuracy or customer experience?

Processes scoring high on these criteria are prime candidates for AI implementation.

Step 2: Choose the Right AI Solutions for Your Budget

Not all AI solutions require massive investments. In 2025, small business AI options range from affordable SaaS tools to custom implementations.

Budget-Friendly AI Tools ($50-500/month):

Customer Relationship Management

• HubSpot’s AI-powered lead scoring
• Salesforce Einstein for small teams
• Pipedrive’s sales automation features

Marketing Automation

• Mailchimp’s predictive analytics
• Hootsuite’s AI content scheduling
• Canva’s AI design assistant

Business Operations

• QuickBooks’ AI bookkeeping features
• Calendly’s smart scheduling
• Zapier’s workflow automation

Mid-Range Solutions ($500-2,000/month):

• Custom chatbot development
• Advanced analytics dashboards
• Inventory management AI systems
• Employee scheduling optimization

Enterprise-Level Implementations ($2,000+/month):

• Custom machine learning models
• Computer vision quality control systems
• Predictive maintenance solutions
• Advanced customer analytics platforms

Step 3: Calculate Your AI Implementation ROI

Smart small business owners measure twice and cut once. Before investing in AI, calculate your expected return on investment.

ROI Calculation Framework:

Time Savings Value

• Hours saved per week × hourly wage × 52 weeks = Annual time savings value
• Example: 10 hours/week × $25/hour × 52 = $13,000 annual savings

Revenue Enhancement

• Improved conversion rates × average customer value × annual customers
• Example: 5% conversion improvement × $500 average sale × 1,000 customers = $25,000

Cost Reductions

• Reduced errors, fewer returns, lower customer service costs
• Example: 20% reduction in customer service calls × $50 per call × 2,000 calls = $20,000

Total Annual Benefit: $58,000 Annual AI Investment: $12,000 ROI: 383%

This framework helps justify AI investments to stakeholders and ensures you’re making data-driven decisions.

Step 4: Implementation Best Practices

Successful AI implementation follows proven methodologies. Here’s how to ensure your small business AI project succeeds:

Phase 1: Planning and Preparation (Weeks 1-2)

• Define clear objectives and success metrics
• Assess data quality and availability
• Identify key stakeholders and champions
• Create an implementation timeline

Phase 2: Pilot Testing (Weeks 3-6)

• Start with a small, low-risk use case
• Test with a limited user group
• Gather feedback and iterate quickly
• Document lessons learned

Phase 3: Full Deployment (Weeks 7-10)

• Roll out to all relevant users
• Provide comprehensive training
• Monitor performance metrics closely
• Establish ongoing support processes

Phase 4: Optimization and Scaling (Weeks 11+)

• Analyze performance data
• Fine-tune algorithms and processes
• Identify additional AI opportunities
• Plan next implementation phase

Real-World Success Stories

Case Study 1: Local Restaurant Chain Challenge: Managing inventory across 5 locations AI Solution: Predictive analytics for demand forecasting Results: 30% reduction in food waste, 15% increase in profit margins

Case Study 2: Manufacturing Startup Challenge: Quality control consistency AI Solution: Computer vision inspection system Results: 95% defect detection accuracy, 50% reduction in manual inspection time

Case Study 3: E-commerce Retailer Challenge: Customer service scalability AI Solution: Intelligent chatbot with human handoff Results: 80% of inquiries resolved automatically, 24/7 customer support coverage

Common Implementation Pitfalls to Avoid

Learning from others’ mistakes can save you time and money:

1. Starting Too Big : Begin with simple, high-impact use cases
2. Ignoring Data Quality : Clean, organized data is essential for AI success
3. Skipping User Training : Even the best AI tools fail without proper adoption
4. Unrealistic Expectations : AI is powerful but not magic—set realistic timelines
5. Going It Alone : Partner with experienced AI consultants for complex implementations

Getting Started: Your Next Steps

Ready to implement AI in your small business? Here’s your action plan:

Week 1:

• Complete the AI readiness assessment
• Research 3-5 relevant AI tools for your industry
• Calculate potential ROI for your top opportunities

Week 2:

• Schedule demos with AI solution providers
• Consult with artificial intelligence consulting experts
• Create an implementation budget and timeline

Week 3:

• Select your first AI implementation
• Begin pilot testing with a small team
• Document your process for future scaling

Why Partner with AI Consulting Experts

While many AI tools are user-friendly, working with experienced artificial intelligence consulting professionals can accelerate your success and avoid costly mistakes. Professional AI consultants bring:

• Industry-specific expertise and best practices
• Technical knowledge for complex integrations
• Objective vendor evaluation and selection
• Ongoing support and optimization services
• Strategic guidance for long-term AI adoption

The investment in professional AI consulting often pays for itself through faster implementation, better tool selection, and avoiding common pitfalls.

Conclusion: The Future is AI-Powered

Small business AI implementation is no longer a luxury—it’s a necessity for staying competitive in 2025 and beyond. By following this step-by-step guide, calculating your ROI, and learning from real-world examples, you can successfully integrate AI into your operations and unlock significant growth opportunities.

Remember, the goal isn’t to implement AI for its own sake, but to solve real business problems and create measurable value. Start small, measure results, and scale what works.

Ready to explore how AI can transform your small business? The journey begins with a single step—and the competitive advantages await those bold enough to take it.

Need help implementing AI in your small business? RavSam Web Solutions specializes in artificial intelligence consulting for small and medium businesses. Contact us for a free AI readiness assessment and discover how we can help you leverage AI for growth.

Related Resources:

• Small Business AI Tools Comparison Chart
• AI Implementation Checklist Template
• ROI Calculator Spreadsheet

In the past few weeks, I’ve been working on the MR for my lookahead algorithm. And now, it’s finally merged ! There’s still some more work to be done—particularly around the testing code—but the core change is finished, and is live.

Suboptimal code?

While working on my MR, I noticed that one of my functions, word_set_remove_unique () , could be optimized. Here is the function:

void
word_set_remove_unique (WordSet *word_set1, WordSet *word_set2)
{
 g_hash_table_foreach_steal (word_set1, word_not_in_set, word_set2);
}

/* Helper function */
static gboolean word_not_in_set (gpointer key,
 gpointer value,
 gpointer user_data)
{
 WordIndex *word_index = (WordIndex *) key;
 WordSet *word_set = (WordSet *) user_data;
 return !g_hash_table_contains (word_set, word_index);
}

word_set_remove_unique () takes two sets and removes any elements in the first set that don’t exist in the second set. So essentially, it performs a set intersection, in-place, on the first set.

My lookahead function calls word_set_remove_unique () multiple times, in a loop. My lookahead function always passes in the same persisted word set— clue_matches_set —as the first set. The second set changes with each loop iteration. So essentially, my lookahead function uses word_set_remove_unique () to gradually refine clue_matches_set .

Now, importantly, clue_matches_set is sometimes larger than the second word set—potentially several orders of magnitude larger. And because of that, I realized that there was an optimization I could make.

An obvious optimization

See, g_hash_table_foreach_steal () runs the given boolean function on each element of the given hash table, and it removes the element if the function returns TRUE . And my code always passes in word_set1 as the hash table (with word_set2 being passed in as user_data ). This means that the boolean function is always run on the elements of word_set1 ( clue_matches_set ).

But word_set1 is sometimes smaller than word_set2 . This means that g_hash_table_foreach_steal () sometimes has to perform this sort of calculation:

WordSet *word_set1; /* Contains 1000 elements. */
WordSet *word_set2; /* Contains 10 elements. */

for (word : word_set1)
 {
 if (!g_hash_table_contains (word_set2, word))
 g_hash_table_remove (word_set1, word);
 }

This is clearly inefficient. The point of word_set_remove_unique () is to calculate the intersection of two sets. It’s only an implementation detail that it does this by removing the elements from the first set.

The function could also work by removing the unique elements from the second set. And in the case where word_set1 is larger than word_set2 , that would make more sense. It could be the difference between calling g_hash_table_contains () (and potentially g_hash_table_remove () ) 10 times and calling it 1000 times.

So, I thought, I can optimize word_set_remove_unique () by reimplementing it like this:

1. Figure out which word set is larger.
2. Run g_hash_table_foreach_steal () on the larger word set.
3. If the second set was the larger set, then swap the pointers.

/* Returns whether or not the pointers were swapped. */
gboolean
word_set_remove_unique (WordSet **word_set1_pp, WordSet **word_set2_pp)
{
 WordSet *word_set1_p = *word_set1_pp;
 WordSet *word_set2_p = *word_set2_pp;
 if (g_hash_table_size (word_set1_p) <= g_hash_table_size (word_set2_p))
 {
 g_hash_table_foreach_steal (word_set1_p, word_not_in_set, word_set2_p);
 return FALSE;
 }
 else
 {
 g_hash_table_foreach_steal (word_set2_p, word_not_in_set, word_set1_p);
 *word_set1_pp = word_set2_p;
 *word_set2_pp = word_set1_p;
 return TRUE;
 }
}

Not so obvious?

Well, I made the change, and…it’s actually slower.

We have some profiling code that measures how long each frame takes to render. The output looks like this:

update_all():
 Average time (13.621 ms)
 Longest time (45.903 ms)
 Total iterations (76)
 Total number of iterations longer than one frame (27)
 Total time spent in this function (1035.203f ms)

word_list_find_intersection():
 Average time (0.774 ms)
 Longest time (4.651 ms)
 Total iterations (388)
 Total time spent in this function (300.163f ms)

And when I compared the results of the optimized and unoptimized word_set_remove_unique () , it turned out that the “optimized” version performed either worse or about the same. That just goes to show the value of profiling!

More testing needed

So…that was going to be the blog post. An optimization that turned out to not be so optimal. But in writing this post, I reimplemented the optimization—I lost the original code, because I never committed it—and that is the code that you see. But when I tested this code, it seems like it is performing better than the unoptimized version. So maybe I messed up the implementation last time? In any case, more testing is needed!

This week is the last week of Google Summer of Code for this year edition, and I'll do a summary of what we have been doing and future plans for the Log Detective integration in openSUSE.

I wrote a blog post about this project when it starts, so if you didn't read, you can take a look .

All the work and code was done in the logdetective-obs github repository .

Aazam, aka the intern, also wrote some blog post about his work .

Initial Research

The idea of the project was to explore ways of integration of LogDetective with the openSUSE dev workflow. So we started collecting some build failures in the openSUSE build service and testing with log detective to check if the output is smart or even relevant.

The intern creates a script to collect log from build failures and we store the LLM answer.

Doing this we detected that the log-detective.com explain is very slow and the local tool is less accurate.

The results that we got weren't too good, but at this point of the project is something expected. The model is being trained and will improve with every new log that users send.

Local vs Remote, model comparison

The logdetective command line tool is nice, but LLM requires a lot of resources to run locally. This tool also uses the models published by fedora in huggingface.co , so it's not as accurate as the remote instance that has a better trained model and is up to date.

In any case, the local logdetective tool is interesting and, at this moment, it's faster than the deployed log-detective.com.

Using this tool, Aazam did some research, comparing the output with different models .

logdetective apache-arrow_standard_x86_64.log\
  --model unsloth/Qwen2.5-Coder-7B-Instruct-128K-GGUF\
  -F Qwen2.5-Coder-7B-Instruct-Q4_K_M.gguf\
  --prompt ~/prompt.yaml

So using other specific models, the logdetective tool can return better results.

The plugin

openSUSE packagers uses the osc tool, to build packages in build.opensuse.org. This tool can be extended with plugins and we created a new plugin to use log-detective.

So a packager can get some AI explanation about a build failure with a simple command:

$ osc ld -r -p devel:languages:python --package python-pygame --repo openSUSE_Tumbleweed
🔍 Running logdetective for python-pygame (openSUSE_Tumbleweed/x86_64)...
Log url: https://api.opensuse.org/public/build/devel:languages:python/openSUSE_Tumbleweed/x86_64/python-pygame/_log
🌐 Sending log to LogDetective API...
 The RPM build process for the `python-pygame` package failed during the
`%check` phase, as indicated by the "Bad exit status from /var/tmp/rpm-
tmp.hiddzT (%check)" log snippet. This failure occurred due to seven test
failures, one error, and six skipped steps in the test suite of the package.



The primary issue causing the build failure seems to be the traceback error in
the `surface_test.py` file, which can be seen in the following log snippets:



[[  278s] Traceback (most recent call last):
[  278s]   File "/home/abuild/rpmbuild/BUILD/python-
pygame-2.6.1-build/BUILDROOT/usr/lib64/python3.11/site-
packages/pygame/tests/surface_test.py", line 284, in test_copy_rle
]
[[  278s] Traceback (most recent call last):
[  278s]   File "/home/abuild/rpmbuild/BUILD/python-
pygame-2.6.1-build/BUILDROOT/usr/lib64/python3.11/site-
packages/pygame/tests/surface_test.py", line 274, in
test_mustlock_surf_alpha_rle
]
[[  278s] Traceback (most recent call last):
[  278s]   File "/home/abuild/rpmbuild/BUILD/python-
pygame-2.6.1-build/BUILDROOT/usr/lib64/python3.11/site-
packages/pygame/tests/surface_test.py", line 342, in test_solarwolf_rle_usage
]



These traceback errors suggest that there are issues with the test functions
`test_copy_rle`, `test_mustlock_surf_alpha_rle`, and `test_solarwolf_rle_usage`
in the `surface_test.py` file. To resolve this issue, you should:



1. Identify the root cause of the traceback errors in each of the functions.
2. Fix the issues found, either by modifying the test functions or correcting
the underlying problem they are testing for.
3. Re-build the RPM package with the updated `surface_test.py` file.



It's also recommended to review the other test failures and skipped steps, as
they might indicate other issues with the package or its dependencies that
should be addressed.

Or if we are building locally, it's possible to run using the installed logdetective command line. But this method is less accurate, because the model used is not smart enough, yet:

$ osc build
[...]
$ osc ld --local-log --repo openSUSE_Tumbleweed
Found local build log: /var/tmp/build-root/openSUSE_Tumbleweed-x86_64/.build.log
🚀 Analyzing local build log: /tmp/tmpuu1sg1q0
INFO:logdetective:Loading model from fedora-copr/Mistral-7B-Instruct-v0.3-GGUF
...

Future plans

1. Adding submit-log functionality to osc-ld-plugin . In-progress . This will make it easier to collaborate with log-detective.com, allowing openSUSE packagers to send new data for model training.
2. Gitea bot. openSUSE development workflow is moving to git , so we can create a bot that comment on Pull Request with packages that fails to build. Something similar to what fedora people have for centos gitlab
3. Add a new tab to log-detective.com website to submit logs directly from OBS

This was an interesting Summer of Code project. I learned a bit about LLM. I think that this project has a lot of potential, this can be integrated in different workflows and an expert LLM can be a great tool to help packagers, summarizing big logs, tagging similar failures, etc.

We have a lot of packages and a lot of data in OBS , so we should start to feed the LLM with this data, and in combination with the fedora project, the log-detective could be a real expert in open source RPM packaging.

One of the pieces of the Python standard library I tend to use the most is argparse . It is really convenient to use so I chose to implement that in Pystd. The conversion was fairly simple, with one exception. As C++ is not duck typed, adapting the behaviour to be strictly typed while still feeling "the same" took some thinking. Parsing command line options is also quite complicated and filled with weird edge cases. For example, if you have short options -a and -b , then according to some command line parsers (but not others) an argument of -ab is valid (but only sometimes).

I chose to ignore all the hard bits and instead focus on the core parts that I use most of the time, meaning:

• Short and long command line arguments
• Arguments can be of type bool, int, string or array of strings
• Full command line help
• Same actions as in argparse

The only cheat is that I did the column alignment by hand due to laziness. Using the new implementation resembles regular argparse (full code is here ). First you create the parser and options:

Then you do the parse and use the results:

Compiling this test application and all support code from scratch takes approximately 0.2 seconds.

Foundry

• Spent a bit of time working out how we can enable selection of app patterns in Foundry. The goal here would be to have some very common libadwaita usage patterns available for selection in the new-project guide.

  Ultimately it will rely on FoundryInputCombo / FoundryInputChoice but we’ll have to beef it up to support iconography.

• Finish up a couple speed-runs so they can be uploaded to to gitlab. chergert/assist and chergert/staged are there and can serve as an example of how to use the libfoundry API.

• A big portion of this week has been figuring out how I want to expose tweaks from libfoundry into applications. There are a lot of caveats here which make it somewhat tricky.

  For example, not every application will need every toggle, so we need a way to filter them. GListModel is probably our easiest way out with this, but we’ll likely need a bit more control over provenance of tweaks here for filtering.

• Tweak engine has a new “path” design which allows us to dynamically query available tweaks as you dive down deeper into the UI. This is primarily to help avoid some of the slower parts of the tweaks engine in GNOME Builder.

  Also, to help support this, we can define tweaks using static data which allows for registration/query much faster. For example, there is no need to do UI merging since that can happen automatically.

  There are also cases where you may need to register tweaks which are more complex than simple GSettings . We should be able to accommodate that just fine.

• Added API for add/remove to Git stage. Much simpler than using the libgit2 index APIs directly, for the common things.

  We may want to add a “Stage” API at some point. But for now, the helpers do the job for the non-partial-stage use-case.

  Just foundry_git_vcs_stage_entry (vcs, entry, contents) where the entry comes from your status list. You can retrieve that with foundry_git_vcs_list_status (vcs) . If you are brave enough to do your own diff/patch you can implement staging lines with this too.

  However, that is probably where we want an improved stage helper.

• Added API for creating commits.

  Much easier to do foundry_git_vcs_commit (vcs, msg, name, email) than the alternatives.

• Running LLM tools can now be done through the conversation object which allows for better retention of state. Specifically because that can allow the conversation to track a history object other than a simple wrapped FoundryLlmMessage .

  For example, some message subclasses may have extra state like a “directory listing” which UI could use to show something more interesting than some text.

• Simplify creating UI around FoundryLlmConversation with a new busy property that you can use to cancel your in-flight futures.

• Fixed an issue where running the LLM tool (via subprocess) would not proxy the request back to the parent UI process. Fixing that means that you can update the application UI when the conversation is running a tool. If you were, for example, to cancel the build then the tool would get canceled too.

• Made the spellcheck integration work the same as we do in Builder and Text Editor which is to move the cursor first on right-click before showing corrections.

Libspelling

• New release with some small bugfixes.

Levers

• Another speed run application which is basically the preferences part of Builder but on top of Foundry. The idea here is that you can just drop into a project and tweak most aspects of it.

  Not intended to be a “real” application like the other speed-runs, but at least it helps ensure that the API is relatively useful.

On the spring 2024 I presented my candidature , and eventually got elected for the Board of Directors at the GNOME Foundation. Directors are elected democratically by the GNOME Foundation members, and positions are usually up for election every 2 years. However, when I started my term there was one position open for a single year (due to some changes in composition of the Board). And I volunteered for it, thus my term expired more or less a month ago. When directors get elected, the information that voters have to decide on their vote is:

• Their personal connection to the candidates
• The candidatures themselves
• And further questions the voters might ask about specific topics

For the shake of transparency and accountability, I am going to discuss my own personal candidature against the work that I contributed to the Board for the last year. Although pretty basic and a self-assessment, I believe this is important for any organization. Without retrospectives, feedback, and public discussion it is very hard to learn lesson, make improvements, and ensure knowledge transfer. Not to mention that public scrutiny and discussion are crucial for any kind of functional democratic governance. Though there are reasons to sometimes not discuss things in public, most of my work for the last year can indeed be discussed in public.

Candidature goals

I joined the Board to contribute mostly from the economic perspective. I wanted to become part of the Finance Committee to contribute to improve:

• The communication about economic and funds-related topics. My goal was to ensure that funds were handled more transparently, and build trust by making sure the information reported was detailed and correct. Avoiding issues like those of which I spoke in a previous blog post .
• The way funds were assigned, to make sure those were spent on fulfilling the goals we set to the Foundation.

Unfortunately, when I joined the Board there were some considerable governance issues still unresolved that we got handed over from the previous year. Given my status as a developer and recent community member based in Europe, I had not had time to build relationships with many people in the community. As such, I also set it as one of my goals to represent those people that I knew, which had been under-represented in the previous board.

Goals into actions

Let it be said that being part of a governance body for a non-profit in a foreign country with a different history and legal background can be challenging. A non-trivial amount of my time was dedicated to understanding and getting used to such a body: its internal rules, ways of working, and expectations. I wish the governance was closer to home (has anybody in the American continent worked in organizations with a General Assembly?), but that would be a discussion for another time. Now I will stick to discussing actions related to the goals above.

Becoming part of the Finance Committee

I presented my candidature to become the Treasurer. The Board did a vote , and instead decided to appoint me as Vice-treasurer. As such, I had no powers, more than the right to attend the Finance Committee meetings, which was enough for me to work on my other self-stated goals. Unfortunately, despite multiple requests from different Board members, and assurances in different meetings , I was never called to a Finance Committee meeting. With the resignation of Michael Downey as a directory during the change of the year, I was then offered the Treasurer position. I declined the offer, since at that point I was not willing to volunteer more of my time for the Foundation.

Economic-related communication and funds

During the first months of my term I got heavily involved in this aspect. In addition to taking part in discussions and decision-making, I was one of the the main authors of a general economic update and one focused specifically on the budget . It of course took input and effort from multiple directors, but I am confident that my contribution was considerable. Happily, those updates did have an impact on how people saw the Foundation and the project, with some hints that such work could help regain good will and trust from further people in the membership and the wider FOSS community. Those two were concentrated in the first half of my term, and although there are usually more economic news around budget planning, I did not contribute further work on this for the second half of my term.

Regarding the usage of funds, I was quite involved in the drafting and approval of the budget for 2024/2025. Even if Richard (then Interim Executive Director) took the lion’s share of the work. Such budget managed to retain spending essential for the fulfilling of the goals (conferences, infra), while at the same time making sure available restricted funds were put to use (parental controls and well-being). Unfortunately, some of the fears I expressed in my candidature were right, and expenses had to be cut considerably, leading to us not being able to support all the previous staffers. In general, those executive decisions were not made by me, but by the Executive Director. However, I am happy my input was taken into consideration, and we managed to have a budget that brought us to 2025.

Governance and community engagement

Although the governance issues were carried over from a previous board, I tried to apply the best of my judgement in every situation. I did communicate, when the situation allowed, with the community, and sit in countless meetings to both mediate and express my opinion. At some point, when I was not sure I was doing a good job, presented my resignation a considerable amount of people I knew had voted for me, and all considered it would be best for me to stay.

Evaluation

I put a lot of effort and time moving forward those things I promised in the first half of my term. Unfortunately, I was unable to continue with such engagement through the second half. Part of that had to be with bad management of my time and energy, where I surely burned too much too early. Another part had to be with the realization that many of the problems that I was hoping to tackle at the Foundation are symptoms of deeper structural issues at the project level. For example, no team or committee has official and effective communication channels. So why would the people running the project change their behavior just because being part of  the Board? I believe I do not have the leverage, skills, or experience to tackle those issues at their core, which strongly reduced my motivation. I am happy, though, that senior members in the community are really trying .

I am specially sorry I did not take the Treasurer position when I was offered it. This was less than I expected from myself. I offered my resignation to community members that I knew had voted me, but nobody took it. I also presented my resignation to another Board member which took most of the burden for my decision of not taking the role. It was also politely declined. In hindsight I maybe should have resigned anyway.

On the positive side, I learned a lot of lessons just by being on the Board, specially related to governance. I take most of those lessons with me to postmarketOS , and I hope they serve as an useful inter-FOSS lesson sharing experiment. They have surely already helped!

Overall, I am a bit disappointed with myself, as I would have expected to keep doing a lot of the things I did at the beginning for the whole of my term. At the same time, considering the complete year, I think my overall level of work and engagement was probably on average compared to the rest of the Board. In general, the whole experience was considerably draining, specially emotionally, as we were going through uncommon circumstances, e.g: governance issues, staff reduction, etc.

Moving forward

I do not plan to come back to do governance for the GNOME project for a while. I am very happy with what we are building in postmarketOS: the community and the full-stack and upstreaming commitment we bring with us. I hope the GNOME project and Foundation can transition to more open and structured models of governance, where tracking decisions, communicating regularly, and taking responsibility over good and bad decisions becomes the norm. I hope this posts motivates other directors to write their own retrospectives and hold themselves accountable in public in the future.

It is also encouraging to see that we have a new Executive Director, Steven, which rapidly understood many of the issues and needs of the project and organization in a similar way than I do. I wish him the best of successes, and thank him for taking over such an endeavor.

Thanks also to every Board member: Cassidy, Erik, Federico, Julian, Karen, Michael, Philip, Robert, as well as the staff I interacted Rosanna, Kristi, Bart, and Richard. I’ve seen the passion and effort, and it is truly remarkable. With this, I also want to give a special mention to Allan Day. He’s worked non-stop during months to decisively contribute to the Foundation staying afloat. Thank you very much for your work, it is unmatched.

If you have any feedback you want to share, thoughts about my term, improvements to suggest, or just some thanks, feel free to comment or email me. I am always happy to hear other people’s thoughts, and there’s no improvement without feedback!