<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kospex - Git Analytics</title><link>https://kospex.io/</link><description>Recent content on Kospex - Git Analytics</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 12 Jul 2026 10:00:00 +1000</lastBuildDate><atom:link href="https://kospex.io/index.xml" rel="self" type="application/rss+xml"/><item><title>About Kospex</title><link>https://kospex.io/about/</link><pubDate>Sun, 12 Jul 2026 10:00:00 +1000</pubDate><guid>https://kospex.io/about/</guid><description>&lt;h2 id="why-kospex-exists"&gt;Why Kospex exists&lt;/h2&gt;
&lt;p&gt;Kospex started with a question that kept coming up on security and code reviews: &lt;em&gt;if no one here knows this code, how would we fix it?&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;Walk into an organisation with a few hundred repositories and you can usually get a vulnerability report within a day. What is much harder to answer is who understands the code well enough to act on it. Which repositories have no active contributors left. Which systems depend on one person who is about to change teams or resign. Which dependencies have drifted so far behind that a &amp;ldquo;just bump the version&amp;rdquo; fix turns into weeks of work.&lt;/p&gt;</description></item><item><title>Contact Us</title><link>https://kospex.io/contact-us/</link><pubDate>Sun, 12 Jul 2026 10:00:00 +1000</pubDate><guid>https://kospex.io/contact-us/</guid><description>&lt;!-- Contact Section --&gt;
&lt;section id="contact" class="contact"&gt;
 &lt;div class="container"&gt;
 &lt;div class="section-title"&gt;
 &lt;div class="contact"&gt;
 &lt;iframe data-tally-src="https://tally.so/embed/w4VqX5?alignLeft=1&amp;transparentBackground=1&amp;dynamicHeight=1" loading="lazy" width="100%" height="387" frameborder="0" marginheight="0" marginwidth="0" title="Contact form"&gt;&lt;/iframe&gt;
 &lt;script&gt;var d=document,w="https://tally.so/widgets/embed.js",v=function(){"undefined"!=typeof Tally?Tally.loadEmbeds():d.querySelectorAll("iframe[data-tally-src]:not([src])").forEach((function(e){e.src=e.dataset.tallySrc}))};if("undefined"!=typeof Tally)v();else if(d.querySelector('script[src="'+w+'"]')==null){var s=d.createElement("script");s.src=w,s.onload=v,s.onerror=v,d.body.appendChild(s);}&lt;/script&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
&lt;/section&gt;</description></item><item><title>Are security vulnerabilities an indicator of development testing practices?</title><link>https://kospex.io/articles/vulnerabilities-testing-indicator/</link><pubDate>Mon, 10 Mar 2025 18:34:57 +1100</pubDate><guid>https://kospex.io/articles/vulnerabilities-testing-indicator/</guid><description>&lt;p&gt;&lt;em&gt;TLDR&lt;/em&gt;: Security vulnerabilities might be an indicator of low automated unit, integration and regression testing capabilities. Finding vulnerabilities is easier than fixing them as bug fixes need to be tested. Identifying libraries that are getting behind in versions is one indicator of code repository health.&lt;/p&gt;
&lt;p&gt;When I first meet a development team, I like to ask three questions to gain an understanding of where they are at:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;How often do you release? (e.g. daily, weekly, monthly, quarterly, on demand or adhoc)&lt;/li&gt;
&lt;li&gt;How often can you release? (e.g. they can release quickly but don&amp;rsquo;t)&lt;/li&gt;
&lt;li&gt;How much manual testing is required per release?&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;While answers can be subjective, when there is a higher manual testing and a longer release cycle it more likely it&amp;rsquo;s going to be harder (or more intensive) to test security fixes and their impacts.&lt;/p&gt;</description></item><item><title>What are orphaned repos and why should you care</title><link>https://kospex.io/articles/orphaned-repos/</link><pubDate>Mon, 10 Mar 2025 17:50:26 +1100</pubDate><guid>https://kospex.io/articles/orphaned-repos/</guid><description>&lt;p&gt;&lt;em&gt;TLDR:&lt;/em&gt; If no one knows the code, how will you fix or redeploy it? Knowledge of code is important to maintain, operate and make bug or security fixes. However, removing unused repos might improve focus by removing clutter.&lt;/p&gt;
&lt;p&gt;In the book, The Mythical Man-Month by Fred Brooks, it talks about disproportionate amount of time developers spend thinking compared to coding. Some say that that source code is only 30% of the development process, with thinking, discussions and discovery being the other 70%. So even if we&amp;rsquo;ve got the code, we&amp;rsquo;re missing the thinking which is still in the developers head. Even documentation might not do justice to that days or weeks of thinking and discussions which occurred.&lt;/p&gt;</description></item></channel></rss>