<div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Feb 14, 2019 at 9:58 PM Till Kamppeter &lt;<a href="mailto:till.kamppeter@gmail.com">till.kamppeter@gmail.com</a>&gt; wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 14/02/2019 18:49, Kurt Pfeifle wrote:<br>
&gt; This is not correct.<br>
&gt; <br>
&gt; Avahi was initially created by Trend Lloyd in early 2004. He was <br>
&gt; certainly inspired by Apple&#39;s Bonjour, which unfortunately was not Open <br>
&gt; Source initially, so there as a strong motivation to implement a FOSS <br>
&gt; ZeroConf stack, since all of the relevant specs (mDNS + DNS-SD) were <br>
&gt; already there at IETF, and open.<br>
&gt; <br>
&gt; Later that same year Lennart Poettering started a similar project to <br>
&gt; implement mDNS/DNS-SD functionality called &quot;FlexMDNS&quot;.<br>
&gt; <br>
&gt; Both projects united and merged their code bases sometime in 2005. <br>
&gt; Though I have no idea which of the two guys wrote more lines of code <br>
&gt; that still exists in today&#39;s code base, Poettering surely had a heavy <br>
&gt; impact on today&#39;s Avahi.<br>
&gt; <br>
&gt; Apple released Bonjour as Open Source software under the Apache License <br>
&gt; only in 2006.<br>
&gt; <br>
&gt; Avahi&#39;s name certainly was Trend&#39;s decision, and he started his <br>
&gt; implementation half a year before Poettering.<br>
&gt; <br>
&gt; Poettering&#39;s last commit into Avahi&#39;s GitHub code was in Sept  2012. <br>
&gt; Trend&#39;s last commit was 10 days ago. The last time Trend merged a major <br>
&gt; pull request was in August 2018. See <br>
&gt; <a href="https://github.com/lathiat/avahi/commits?author=lathiat" rel="noreferrer" target="_blank">https://github.com/lathiat/avahi/commits?author=lathiat</a>.<br>
&gt; <br>
&gt;   According to <a href="https://github.com/lathiat" rel="noreferrer" target="_blank">https://github.com/lathiat</a> Trend works for Canonical.<br>
&gt; <br>
<br>
That is interesting to know. Now I understand why Trent does not like <br>
that someone will take the project away from him.<br></blockquote><div><br></div><div>In any case, starting at the last link I provided, this leads, within 5 minutes to...</div><div><br></div><div>* ...his info that he works for Canonical,</div><div>* ...an email address registered by Trent with GitHub,</div><div>* ...a website run by him showing his Twitter handle,</div><div>* ...confirming his Canonical association info,</div><div>* ...showing his frequent Twitter activity.</div><div><br></div><div>In the same time span spent at <a href="https://github.com/lathiat/avahi/issues">https://github.com/lathiat/avahi/issues</a> I </div><div>could not identify...</div><div><br></div><div>* ...any bug reports related to problems created by Avahi shortcomings</div><div>   for CUPS printing as mentioned before,</div><div>* ...any pull requests submitted at GitHub to solve these problems.</div><div><br></div><div>But maybe I was not aware of what I should search for....</div><div><br></div><div>However I noted the following Avahi statistics on GitHub:</div><div><br></div><div>* 81 open vs. 43 closed Issues.</div><div>* 39 open vs. 55 closed Pull Requests.</div><div><br></div><div>So indeed, the activities on Avahi have slowed down in recent years.</div><div>But it is not the case that Trent is missing from planet earth or turned</div><div>un-interested regarding computer-related topics.</div><div><br></div><div>So my advice would be the following:</div><div><br></div><div>* Create the relevant bug reports (&quot;issues&quot;) for Avahi on GitHub.</div><div>* Create the most wanted feature requests for Avahi on GitHub.</div><div>* For each bug and feature supply a pull request on GitHub.</div><div>* Upvote/comment/like/discuss these new activities on Avahi&#39;s GitHub.</div><div>* Contact Trent via Twitter (where he seems most responsive) about </div><div>   the Github issues and ask for his comments.</div><div>* If he does not show any willingness to integrate well done pull</div><div>   requests, then only seriously consider a fork on the project. Y&#39;all</div><div>   will have an easier way to convince people about the need for </div><div>   such a drastic step, if your PRs are sitting there for too long. Also</div><div>   a fork will have a headstart, if the code to add/improve is already</div><div>   waiting there, well-tested.</div><div><br></div><div>Don&#39;t just jump into such an adventure based on rumours, un-prepared and without your troops well-equipped.</div><div><br></div><div><br></div></div></div></div>