MobileRead Forums - View Single Post

3333 · 08-07-2026, 08:14 AM

Hi KevinH,

Greetings from the "hostile Chinese Sigil-Enhanced fork".

English is not my native language, so I'm using translation software.

I actually posted a more detailed reply in the earlier Sigil-Enhanced thread:
https://www.mobileread.com/forums/sh...d.php?t=374448

For some reason, though, my reply does not appear to be visible on the forum. I don't know what happened to it, so please excuse me for repeating some of the context here.

I'm glad to see that the BookBrowser optimization was useful enough to be incorporated into Sigil. You are absolutely welcome to use it.

I did find the description "hostile" rather curious, though.

As far as I know, Sigil-Enhanced has never attacked Sigil, discouraged anyone from using Sigil, restricted Sigil from using our changes, or attempted to compete with the upstream project. What we have admittedly failed to do so far is communicate with upstream early enough.

That is a communication problem, not hostility.

And since code from Sigil has flowed into Sigil-Enhanced, while code from Sigil-Enhanced is now flowing back into Sigil, it seems that the "one-way street" may already have acquired a second lane.

That is exactly how open source should work, in my view.

There is also a useful example of how 3tic-project has handled this exact situation before.

We maintain another project called OrionCrane:

https://github.com/3tic-project/OrionCrane

OrionCrane started as a specialized fork of the Crane Rust inference engine. We created it because we needed an inference engine heavily optimized for models we were training ourselves and for workloads that were quite specific to our own use case.

While that work was still changing rapidly, we developed it separately. We did not expect the original Crane project to absorb every experimental optimization or project-specific decision as soon as we wrote it.

But once the work became mature enough, we extracted the parts that were generally useful and contributed them upstream.

Those contributions were not merely offered — a series of them were merged into Crane. Several of those are now substantial parts of what upstream Crane itself provides and advertises.

So this is not a new philosophy invented in response to criticism of Sigil-Enhanced. We have already followed this development model elsewhere:

specialize first, experiment freely, stabilize the implementation, then separate the broadly useful work and contribute it upstream.

That is also what I intend to do with Sigil-Enhanced.

The project is still highly experimental and specialized, so I have deliberately avoided sending upstream a large number of unstable or niche changes. Once the implementations settle down, generally useful fixes, performance improvements, and implementation findings will be separated and shared upstream.

So I am happy to accept criticism for not communicating sooner.

"Hostile", however, seems a little dramatic for two GPL projects already exchanging useful code — particularly when contributing useful work back upstream is something our other projects have already demonstrated in practice.

08-07-2026, 08:14 AM	#9
3333 Junior Member Posts: 4 Karma: 10 Join Date: Aug 2026 Device: Phone	Hi KevinH, Greetings from the "hostile Chinese Sigil-Enhanced fork". English is not my native language, so I'm using translation software. I actually posted a more detailed reply in the earlier Sigil-Enhanced thread: https://www.mobileread.com/forums/sh...d.php?t=374448 For some reason, though, my reply does not appear to be visible on the forum. I don't know what happened to it, so please excuse me for repeating some of the context here. I'm glad to see that the BookBrowser optimization was useful enough to be incorporated into Sigil. You are absolutely welcome to use it. I did find the description "hostile" rather curious, though. As far as I know, Sigil-Enhanced has never attacked Sigil, discouraged anyone from using Sigil, restricted Sigil from using our changes, or attempted to compete with the upstream project. What we have admittedly failed to do so far is communicate with upstream early enough. That is a communication problem, not hostility. And since code from Sigil has flowed into Sigil-Enhanced, while code from Sigil-Enhanced is now flowing back into Sigil, it seems that the "one-way street" may already have acquired a second lane. That is exactly how open source should work, in my view. There is also a useful example of how 3tic-project has handled this exact situation before. We maintain another project called OrionCrane: https://github.com/3tic-project/OrionCrane OrionCrane started as a specialized fork of the Crane Rust inference engine. We created it because we needed an inference engine heavily optimized for models we were training ourselves and for workloads that were quite specific to our own use case. While that work was still changing rapidly, we developed it separately. We did not expect the original Crane project to absorb every experimental optimization or project-specific decision as soon as we wrote it. But once the work became mature enough, we extracted the parts that were generally useful and contributed them upstream. Those contributions were not merely offered — a series of them were merged into Crane. Several of those are now substantial parts of what upstream Crane itself provides and advertises. So this is not a new philosophy invented in response to criticism of Sigil-Enhanced. We have already followed this development model elsewhere: specialize first, experiment freely, stabilize the implementation, then separate the broadly useful work and contribute it upstream. That is also what I intend to do with Sigil-Enhanced. The project is still highly experimental and specialized, so I have deliberately avoided sending upstream a large number of unstable or niche changes. Once the implementations settle down, generally useful fixes, performance improvements, and implementation findings will be separated and shared upstream. So I am happy to accept criticism for not communicating sooner. "Hostile", however, seems a little dramatic for two GPL projects already exchanging useful code — particularly when contributing useful work back upstream is something our other projects have already demonstrated in practice. Last edited by 3333; 08-07-2026 at 08:18 AM. Reason: Added clarification about Sigil-Enhanced and our upstream contribution approach.