I would like to measure the interest in a fork of Asio, proposed as a Boost library for review. Currently, Boost.Asio (and the standalone version Asio) is developed and maintained by Christopher Kohlhoff. Unfortunately he has a well-earned reputation for being unresponsive to emails and GitHub issues. For example: https://github.com/chriskohlhoff/asio/pull/904 I believe that Asio is Boost's most valuable asset, because "the C++ Standard cannot connect to the Internet." Every other language has portable networking built-in except for C++. Asio is the industry standard and the gold standard for portable networking, yet it is falling behind due to its lack of evolution. A major component of my revitalization plan for Boost is to promote Asio and build many great things on top of it. For example, clients and servers which speak MCP ("Model Context Protocol"), empowering users to easily connect and talk to AI endpoints (Large Language Models) using REST and JSON. Learn more about MCP here: https://www.pulsemcp.com/ In discussions with our staff engineers, there is a movement to propose a Boost.Crypt library with cryptographic primitives as an alternative to OpenSSL, with the goal of modern interfaces which eliminate broad categories of undefined behavior and usage errors which lead to vulnerabilities. Yet if Asio cannot adopt support for alternatives to OpenSSL we cannot evolve. The fork of Asio is just in the idea stage, no work has been done yet, and it is all open to debate and design. My thinking of how the fork would work goes like this: 1. C++ Alliance allocates dedicated staff to maintain the fork 2. Stakeholders come together, on the mailing list and through GItHub issues, to determine what directions we might like to explore or move towards 3. Dedicated staff implement the work and provide support for stakeholders 4. Changes in Asio would be adopted on an as-needed basis The first order of business would be to go through all of the GitHub issues in Asio and address them one by one. What do you think?
On 15 Aug 2025 21:14, Vinnie Falco via Boost wrote:
I would like to measure the interest in a fork of Asio, proposed as a Boost library for review.
Currently, Boost.Asio (and the standalone version Asio) is developed and maintained by Christopher Kohlhoff. Unfortunately he has a well-earned reputation for being unresponsive to emails and GitHub issues. For example:
https://github.com/chriskohlhoff/asio/pull/904
I believe that Asio is Boost's most valuable asset, because "the C++ Standard cannot connect to the Internet." Every other language has portable networking built-in except for C++. Asio is the industry standard and the gold standard for portable networking, yet it is falling behind due to its lack of evolution.
A major component of my revitalization plan for Boost is to promote Asio and build many great things on top of it. For example, clients and servers which speak MCP ("Model Context Protocol"), empowering users to easily connect and talk to AI endpoints (Large Language Models) using REST and JSON. Learn more about MCP here:
In discussions with our staff engineers, there is a movement to propose a Boost.Crypt library with cryptographic primitives as an alternative to OpenSSL, with the goal of modern interfaces which eliminate broad categories of undefined behavior and usage errors which lead to vulnerabilities. Yet if Asio cannot adopt support for alternatives to OpenSSL we cannot evolve.
The fork of Asio is just in the idea stage, no work has been done yet, and it is all open to debate and design. My thinking of how the fork would work goes like this:
1. C++ Alliance allocates dedicated staff to maintain the fork 2. Stakeholders come together, on the mailing list and through GItHub issues, to determine what directions we might like to explore or move towards 3. Dedicated staff implement the work and provide support for stakeholders 4. Changes in Asio would be adopted on an as-needed basis
The first order of business would be to go through all of the GitHub issues in Asio and address them one by one.
What do you think?
Have you discussed this with Christopher? Specifically, if it would be possible to collaborate or co-maintain Asio and/or Boost.Asio.
On Fri, Aug 15, 2025 at 12:12 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
Have you discussed this with Christopher? Specifically, if it would be possible to collaborate or co-maintain Asio and/or Boost.Asio.
This is exactly the problem. Chris does not respond to emails, does not respond to GitHub issues, and has told me in the past that he does not like to interact on social media or in chat rooms. I have asked many times. This is a frustration shared by many. No, it is not possible to collaborate or co-maintain Asio with Chris. Kohlhoff works in high frequency trading firms, which implement valuable proprietary algorithms and require NDAs (non-disclosure agreements). Often he cannot talk about his methods, so keeping quiet is second nature. I believe that Asio for Chris is first a portable network library that he uses in his career, and second an open source offering for users. That is, that Chris evolves Asio in accordance to his needs at work and not in response to users, whose GitHub issues, email, and mailing list posts he simply does not see or read. Therefore, even if Chris was open to collaboration there are many design decisions which we may want to make that he might disagree with. For example, we may consider requiring a more recent version of C++. We might want to use `std::error_code` instead of `boost::system::error_code`. We might want design changes which help other Boost libraries interoperate yet conflict with his vision. All of this is solved with our own fork of Asio. Thanks
Em sex., 15 de ago. de 2025 às 16:36, Vinnie Falco via Boost <boost@lists.boost.org> escreveu:
We might want design changes which help other Boost libraries interoperate yet conflict with his vision. All of this is solved with our own fork of Asio.
If it's going to be a new library with a new design, it should go through the Boost peer review process. I don't know if your idea is going to be sufficiently different to warrant a new library that's mostly going to be an overlap of what Boost.Asio already does though. I'll chime in later with more points. In the meantime, is it my impression or am I the only person who still uses the mailing list asio-users? What should be the alternative for asio-users? Boost-develop or boost-users? I've been developing macros for Boost.Asio, and if they ever get in a state where I think they might be useful to other people, I was planning on announcing it in asio-users. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/
On Fri, Aug 15, 2025 at 1:41 PM Vinícius dos Santos Oliveira < vini.ipsmaker@gmail.com> wrote:
If it's going to be a new library with a new design, it should go through the Boost peer review process.
Yes to the review process, which is why I am first gauging interest. As for the "new design," I am not looking to innovate here. The fork would use the same interface principles as Asio and the same code, except for things that we want to modernize which would not be accepted in original Asio. The canonical example being the use of `std::error_code`. Where we would differ is that there could be support for things that Asio won't do, such as native Botan support for TLS. Or this WolfSSL which is alluded to in the neglected GitHub issue in the OP. I don't know if your idea is going to be sufficiently different to warrant
a new library that's mostly going to be an overlap of what Boost.Asio already does though.
I'm not sure it needs to be sufficiently different, other than having responsive developers and active support. This is why I am posting to the mailing list. Would a fork of Asio which keeps mostly the same interface, has enhancements desired by the community, and has updated documentation and ongoing support worth having as a Boost library?
I'll chime in later with more points. In the meantime, is it my impression or am I the only person who still uses the mailing list asio-users? What should be the alternative for asio-users?
Is asio-users a Boost mailing list? I don't use it. Given the decline in mailing list participation, I think we should try to consolidate all of our mailing list activity down to just a single mailing list (the developer's mailing list). The volume of user traffic is so low, that we should not complain about answering user questions in the developer mailing list. Robust technical discussion is the lifeblood of the Boost library collection and we need to nourish it. Thanks
El 15/08/2025 a las 23:55, Vinnie Falco via Boost escribió:
On Fri, Aug 15, 2025 at 1:41 PM Vinícius dos Santos Oliveira < vini.ipsmaker@gmail.com> wrote:
If it's going to be a new library with a new design, it should go through the Boost peer review process.
Yes to the review process, which is why I am first gauging interest.
As for the "new design," I am not looking to innovate here. The fork would use the same interface principles as Asio and the same code, except for things that we want to modernize which would not be accepted in original Asio. The canonical example being the use of `std::error_code`. Where we would differ is that there could be support for things that Asio won't do, such as native Botan support for TLS. Or this WolfSSL which is alluded to in the neglected GitHub issue in the OP.
I don't know if your idea is going to be sufficiently different to warrant
a new library that's mostly going to be an overlap of what Boost.Asio already does though.
I'm not sure it needs to be sufficiently different, other than having responsive developers and active support. This is why I am posting to the mailing list. Would a fork of Asio which keeps mostly the same interface, has enhancements desired by the community, and has updated documentation and ongoing support worth having as a Boost library?
Hi, Which is the plan to maintain the new features that Asio will get over time? I've not followed Asio evolution, but I guess more features are being added in newer versions (there are some experimental features mentioned in the library documentation). Having support for other SSL libraries (MbedTLS also comes to my mind) is a nice feature. Reducing dependencies to the minimum is also a good feature, although I've seen that the weight of the library has been considerably reduced in the latest Boost releases. If understand the proposal correctly, if the fork passes the review, then we would have 2 networking libraries inside Boost (Boost.Asio + Boost.ForkedAsio)? Best, Ion PS: Building "great things" above a networking library also includes something like Boost.Curl, the C++ swiss army knife for internet protocols?
On Fri, Aug 15, 2025 at 5:20 PM Ion Gaztañaga via Boost < boost@lists.boost.org> wrote:
If understand the proposal correctly, if the fork passes the review, then we would have 2 networking libraries inside Boost (Boost.Asio + Boost.ForkedAsio)?
Yes, exactly. The API of ForkedAsio would closely follow Boost.Asio, and it would pick up changes from Asio. Thanks
El 16/08/2025 a las 5:06, Vinnie Falco via Boost escribió:
On Fri, Aug 15, 2025 at 5:20 PM Ion Gaztañaga via Boost < boost@lists.boost.org> wrote:
If understand the proposal correctly, if the fork passes the review, then we would have 2 networking libraries inside Boost (Boost.Asio + Boost.ForkedAsio)?
Yes, exactly. The API of ForkedAsio would closely follow Boost.Asio, and it would pick up changes from Asio.
Thanks
We have previous experience of having newer versions of a library (Coroutine2, Hash2, Lambda2, Signals2, Variant2), but I think in many of them the API was changed o support newer features or standards. They are in practice, greenfield re-implementations and/or variations. On the other hand, having a lot of newer and shinier features would make Boost.Asio2 more attractive to Boost but it would make tracking the original library increasingly difficult. If we think we can't do it better than Chris, then I don't know what could be the correct path forward. Are networking programmers comfortable with the Asio API or we would like to change the API to make use of newer C++ features? I've read comments from some programmers disliking the Asio interface (the old one and also the interaction with C++ coroutines) but I haven't seen a mature, better alternative yet (and exploring a new API is out of you proposed Boost.ForkedAsio proposal). Best, Ion
A fork seems like a negative value-add, especially if it involves a reliance on paid staff engineers to provide support. A v2 of Asio would be a better project. Asio pioneered quite a bit, and there's a more simple and direct library hiding underneath. I would also not say that Asio is the most valuable Boost library. Also, Asio can work with other TLS implementations fine. There's no need to fork Asio for the sake of using an alternative TLS implementation. - Christian
On Mon, Aug 18, 2025 at 7:46 AM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
I would also not say that Asio is the most valuable Boost library.
You are of course entitled to your own opinion, yet Asio pages are the most frequently visited according to the website logs, and by a large margin. Beast is the second most visited. It should not come as a surprise to you that C++ users desire writing programs which connect to the Internet in order to do things. Regards
Vinnie Falco wrote:
For example, we may consider requiring a more recent version of C++. We might want to use `std::error_code` instead of `boost::system::error_code`.
Chris already uses C++11 in Asio but has deliberately retained system::error_code. Dropping it will lose the error locations.
בתאריך שבת, 16 באוג׳ 2025, 10:16, מאת Peter Dimov via Boost < boost@lists.boost.org>:
Vinnie Falco wrote:
For example, we may consider requiring a more recent version of C++. We might want to use `std::error_code` instead of `boost::system::error_code`.
Chris already uses C++11 in Asio but has deliberately retained system::error_code.
Dropping it will lose the error locations. L
Actually recently in Cppcms Booster.Aio I created when I was dissatisfied with asio I found after porting to c++11 that standard library didn't handle GetSocketError at all so I can understand why... Artyom
On Sat, Aug 16, 2025 at 1:16 AM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Chris already uses C++11 in Asio but has deliberately retained system::error_code.
Dropping it will lose the error locations.
If the proposed Asio2 uses std::error_code instead of boost::system::error_code, there will certainly be a loss of the location functionality. Is it worth it? How many users avoid boost::asio because they perceive the use of boost::system::error_code as a negative? How many users have adopted boost::system::error_code into their code bases just for the location? I don't think many (or realistically, any). I believe that the location functionality is a consolation prize for people who are already using Boost. I don't think the feature is so powerful or so desired that it is driving new users into adopting Boost. What I do hear over and over again is that people want to use standard types, not Boost's alternative types that do the same thing, even if there is some hypothetical value-add. We can debate whether this attitude is rationale, yet I doubt it will be productive to do so as we are not going to be changing anyone's minds. Thanks
On 19 Aug 2025 00:06, Vinnie Falco via Boost wrote:
On Sat, Aug 16, 2025 at 1:16 AM Peter Dimov via Boost <boost@lists.boost.org> wrote:
Chris already uses C++11 in Asio but has deliberately retained system::error_code.
Dropping it will lose the error locations.
If the proposed Asio2 uses std::error_code instead of boost::system::error_code, there will certainly be a loss of the location functionality. Is it worth it? How many users avoid boost::asio because they perceive the use of boost::system::error_code as a negative? How many users have adopted boost::system::error_code into their code bases just for the location? I don't think many (or realistically, any). I believe that the location functionality is a consolation prize for people who are already using Boost. I don't think the feature is so powerful or so desired that it is driving new users into adopting Boost. What I do hear over and over again is that people want to use standard types, not Boost's alternative types that do the same thing, even if there is some hypothetical value-add. We can debate whether this attitude is rationale, yet I doubt it will be productive to do so as we are not going to be changing anyone's minds.
People who don't want to use Boost are unlikely to use your fork, which, presumably, is supposed to be a part of Boost. Those people are probably using standalone Asio or something else entirely instead of Boost.Asio today anyway, and will continue to do so. You seem to target an audience that wants to use Boost but specifically not Boost.System. It seems like a rather narrow audience.
On Mon, Aug 18, 2025 at 2:32 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
People who don't want to use Boost are unlikely to use your fork, which, presumably, is supposed to be a part of Boost. Those people are probably using standalone Asio or something else entirely instead of Boost.Asio today anyway, and will continue to do so.
This is false. I regularly get requests from folks who want to use Beast with standalone Asio. I do not support this configuration for a couple of reasons. First, I don't want there to be two versions of the library. And second, because Beast is sufficiently popular that folks will grudgingly use Boost just so they can have access to Beast (and JSON and URL). Beast has brought in users to Boost that would not have otherwise used Boost, simply because the alternatives for HTTP and Websocket are not great. Nothing stands still however, and this situation has been improving. There are standalone libraries implementing functionality such as HTTP, REST clients and servers, and websocket which are gaining in popularity. Boost's competitive advantage is diminishing over time. A fork of Asio which is well-supported, upon which new things are built (and with reduced dependencies) creates value to give users more reasons to adopt Boost (or to come back to Boost after abandoning it). You seem to target an audience that wants to use Boost but specifically
not Boost.System. It seems like a rather narrow audience.
I use std::error_code as a stand-in for the general desire for users to prefer std library components over their Boost equivalents. Thanks
On 19 Aug 2025 01:00, Vinnie Falco wrote:
On Mon, Aug 18, 2025 at 2:32 PM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
People who don't want to use Boost are unlikely to use your fork, which, presumably, is supposed to be a part of Boost. Those people are probably using standalone Asio or something else entirely instead of Boost.Asio today anyway, and will continue to do so.
This is false. I regularly get requests from folks who want to use Beast with standalone Asio.
I suspect, what these people are actually asking is whether there is a standalone version of Beast that can be used with standalone Asio. Again, I doubt a fork of Asio in Boost will turn them into happy Boost users.
You seem to target an audience that wants to use Boost but specifically not Boost.System. It seems like a rather narrow audience.
I use std::error_code as a stand-in for the general desire for users to prefer std library components over their Boost equivalents.
It doesn't change my point.
Vinnie Falco wrote:
If the proposed Asio2 uses std::error_code instead of boost::system::error_code, there will certainly be a loss of the location functionality. Is it worth it? How many users avoid boost::asio because they perceive the use of boost::system::error_code as a negative?
Zero. The problem with Boost.ASIO is not the use of system::error_code.
How many users have adopted boost::system::error_code into their code bases just for the location?
That's not necessary.
On 15 Aug 2025 22:34, Vinnie Falco wrote:
On Fri, Aug 15, 2025 at 12:12 PM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Have you discussed this with Christopher? Specifically, if it would be possible to collaborate or co-maintain Asio and/or Boost.Asio.
This is exactly the problem. Chris does not respond to emails, does not respond to GitHub issues, and has told me in the past that he does not like to interact on social media or in chat rooms. I have asked many times. This is a frustration shared by many. No, it is not possible to collaborate or co-maintain Asio with Chris.
Incidentally, I recently received a PR from Christopher for Boost.Log[1], to reduce the dependencies caused by Boost.Asio. Which was an issue I reported in Asio[2] not long before. So clearly he does monitor issues and responds by action, where he sees fit. My concern with the proposed fork is the longevity of the project. I agree with Peter that it would be increasingly difficult to maintain, with little practical effect (other than better documentation, I guess). We may end up with unmaintained fork that is incompatible with the main library, which is no longer accessible to Boost libraries (other than as an external dependency). I don't see switching to std::error_code as a big deal, but maintaining this change will take resources that are better spent elsewhere. As for adding support for other cryptography libraries, is it not possible to that externally? I don't work with Asio very often, but from what I remember, the SSL part of it is quite separate from its core. It should be possible to write similar wrappers for other crypto libraries, if needed. Maybe you should consider a new Boost.AsioEx library that hosts such Asio extensions instead of a fork. [1]: https://github.com/boostorg/log/pull/249 [2]: https://github.com/chriskohlhoff/asio/issues/1637
On Fri, Aug 15, 2025 at 6:53 PM Klemens Morgenstern via Boost < boost@lists.boost.org> wrote:
The more I read issues and PRs on asio, the more I understand Chris' policy.
Chris policy is: 1. Not to participate on the mailing list 2. Not to respond to emails 3. Not to engage in discussion with stakeholders 4. Not to respond to GitHub issues The number one portable C++ network library is often giving users a bad experience. We can do better.
Could you elaborate on what kind of evolution you would like to see.
Yes. More examples. Better documentation. Requiring newer versions of C++ and using more standard types.
Why couldn't boost.crypt just implemen It's own crypt-stream type like botan does?
It could. This doesn't solve the stated problem, which is that the Boost networking library that many other libraries depend on (Redis, MySQL, Beast, http-io, websocket-io, cobalt) has an author who is unresponsive to users, unresponsive to emails, unresponsive to the mailing list, and unresponsive to GitHub issues.
That would be design by committee. A lot of stakeholders have input through Chris being part of the industry and they would never participate in an open discussion.
Right, and the design that I am referring to has to do with cosmetic things such as which error code to use. We would not be innovating on the networking API and smarts. Instead we would track the upstream repository. We could however have more examples. Better documentation. And most importantly we could control the GitHub issues and respond to people who open the issues. Even if all of the opened issues are garbage as you imply, then we could explain why they are not actionable and actually close them. This way new visitors to the repository do not see an unmaintained project.
4. Changes in Asio would be adopted on an as-needed basis
And who determines what is needed?
We have to figure that out. Likely we would just track everything.
What do you think?
Horrible idea. Greenfield one to compete with asio and motivate chris to add them this way.
You are suggesting that we create a new networking library from scratch. In my opinion, this is foolish. Chris already did the bulk of the work, and we would be throwing that out. I do not think I can do better than Chris. And I am certain that you cannot do better than Chris. A greenfield solution would be inferior. Furthermore, based on my observations of Chris over 8+ years, he is not the kind of individual who would be "motivated to add them this way." Quite the opposite he would probably be relieved that an alternative exists and he might actually just stop maintaining the Boost version of Asio (which is not used in the HFT systems he works with). Thanks
Hi, Sounds to me like someone who knows Chris just needs to sit down with them and have a chat about how best to maintain the library going forward. I don't think they want it to be taken off their shoulders because they're still adding new features with each release. But it's possible that they would want someone to handle improving the documentation or answering users questions on github, both of which are just as integral to a open source project as good quality code. I'm also not sure what the issue raised with the quality of github issues is, i think this is a common problem across many projects and it means that maintainers do have to spend time answering silly questions. But as winnie the pooh would say doing nothing sometimes leads to the very best of something. If people keep misunderstanding the library then the documentation needs improving. To be clear I think Chris' has done a smashing job in making Boost.ASIO. I think a fork is a bit of nuclear option, the best route i can see is for someone who knows Chris already to sit down with him discuss these issues and how to get around them so we can continue to ensure that C++ has an viable networking library. P.S whatever happened to std::net????? come on C++ you can do better
Vinnie Falco wrote:
Right, and the design that I am referring to has to do with cosmetic things such as which error code to use. We would not be innovating on the networking API and smarts. Instead we would track the upstream repository.
That's going to be a maintenance nightmare. Not impossible, but would take quite a bit of effort from highly determined individuals and the job will get harder and harder with time as the two repos diverge.
Klemens Morgenstern wrote:
https://github.com/chriskohlhoff/asio/pull/904
Have you looked at the PR? It is a build script change for a header only library. The author gives no reason why this is needed or any indication that this works.
The PR is a fix for a previously accepted PR, which has been applied incorrectly.
Vinnie Falco via Boost <boost@lists.boost.org>: I would like to measure the interest in a fork of Asio, proposed as a Boost library for review. That is the beauty of free and open source software. You don't have to ask. Fork it. Make something truly better, prove its value... You don't have to ask anyone. But good luck with it. Asio is incredibly complicated library. I once pored it to non standard platform many years ago and it wasn't easy. I suggest try gaining developer's trust by making real valuable contributions and join as co maintainer. IMHO if something is needed it is a lightweight object oriented alternative to asio instead of template based one when for example stream socket handles both Unix domain socket and tcp without templates. But it is totally different story (one of reasons I created aio library that resembles asio but very different internally) Best Artyom
On Mon, Aug 18, 2025, at 6:34 PM, Artyom Beilis via Boost wrote:
I suggest try gaining developer's trust by making real valuable contributions and join as co maintainer.
I’m going to politely interject that this seems a little tone deaf. Few people have done more to earn trust. They are among the few to have a continuous channel of communication, however scarce. In fact, fellow Alliancers are among top contributors to Asio proper, thinking of e.g. asio::experimental::coro<>. Yet, in an illustrative turn of events it seems thet ended up evolving those ideas into a separate library that was already accepter into Boost (Cobalt). So not only have they proven to have given this a years long effort and *also* gained enough trust to contribute features directly to Asio proper but *also* demonstrated that they know when to add value in a separate library.
IMHO if something is needed it is a lightweight object oriented alternative to asio instead of template based one when for example stream socket handles both Unix domain socket and tcp without templates. This, ironically, would be something you can propose. Far too many (bad) attempts exist in the wild-west (e.g. github). It does seem to have grown increasingly easy (the advent of any_executor, any_completion_handler, associator<Tag, …> traits), so I’m no longer as convinced of the need, but perhaps I’m the wrong target audience.
You don't have to ask. If you don’t, you lost on the “gaining trust” before you started.
Regards, Seth
On Mon, Aug 18, 2025, at 9:24 PM, Seth via Boost wrote:
You don't have to ask. If you don’t, you lost on the “gaining trust” before you started.
That all said, I’m not convinced I saw the convincing reasons for forking. One repeated example was “using std::error_code and friends”. Standalone Asio already does this by default, so it would be a trivial change to split this conditional. However, the choice is on purpose (Boost System has more features than the standard library version), as pointed out by Peter Dimov before. I’ve also seen reasonably responsive behavior from Chris, just mostly on the things he cares about. I’ve been very surprised when Emile Cormier posted his any_completion_handler (https://github.com/chriskohlhoff/asio/issues/1100) idea and Chris landed an improved version … in the next release or close to that. The subsequent work to that feature (and adjacent features like immediate executors, consign, channels etc) do suggest the value in keeping Asio development in one place. This call requires a bit of wisdom, I think. Seth
Am 18.08.2025 um 21:28 schrieb Seth via Boost:
I’ve also seen reasonably responsive behavior from Chris, just mostly on the things he cares about. I’ve been very surprised when Emile Cormier posted his any_completion_handler (https://github.com/chriskohlhoff/asio/issues/1100) idea and Chris landed an improved version … in the next release or close to that. The subsequent work to that feature (and adjacent features like immediate executors, consign, channels etc) do suggest the value in keeping Asio development in one place.
This matches my experiences with Chris' behaviour. As you might know, I maintain a fork with modularized Asio. From time to time I see some of my changes be taken up and incorporated into trunk Asio. It might be mere coincidence, but I don't complain about that. The better trunk Asio is, the easier it is for my fork. Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
Am 22.08.2025 um 17:03 schrieb Vinnie Falco:
On Mon, Aug 18, 2025 at 12:40 PM Daniela Engert via Boost <boost@lists.boost.org> wrote:
Imaintain a fork with modularized Asio.
Where's this fork? What are the differences?
It's here, where it has always been since my CppCon 2022 keynote "Contemporary C++ in Action" : https://github.com/DanielaE/asio This is the Asio that we use in the company for our machines. -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
On Fri, Aug 22, 2025 at 8:09 AM Daniela Engert <dani@ngrt.de> wrote:
It's here, where it has always been since my CppCon 2022 keynote "Contemporary C++ in Action" : https://github.com/DanielaE/asio
Ah yes, I see now. So you have a stack of commits which implement the C++ modules feature in Asio, and every so often you rebase your changes on top of Asio? This is a great example of what a community fork could offer. What we could do is integrate your changes so that the modules feature is built-in to the library, perhaps conditionally using a feature test macro. This way everyone would have the benefit of using modules and asio together, and you would not have to maintain it yourself. The maintenance team would do that (likely paid C++ staff members although volunteers are always welcomed). Thanks
Am 22.08.2025 um 18:05 schrieb Vinnie Falco:
On Fri, Aug 22, 2025 at 8:09 AM Daniela Engert <dani@ngrt.de> wrote:
It's here, where it has always been since my CppCon 2022 keynote "Contemporary C++ in Action" : https://github.com/DanielaE/asio <https://github.com/DanielaE/asio>
Ah yes, I see now. So you have a stack of commits which implement the C++ modules feature in Asio, and every so often you rebase your changes on top of Asio?
Exactly, this is the idea. I take the vanilla version of Asio as the base for my additional, accumulated changes. This way, I benefit from the underlying improvements, and stack my own stuff on top of it: small oversights in the original code, the additional feature of building a named module from the same sources, expelling the sin of TU-local entities (generally discouraged, outright forbidden in modules) that plagues other Boost libraries as well, and progressing into current C++ (like using real C++20 concepts instead of TMP-backed concept emulation in some cases). Whenever I feel like, I perform a rebase and push the new blend into our company codebase. Thanks Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5
For further context here is a rough measurement from the web logs of the number of hits to documentation pages: boost_asio 51424 beast 16686 hana 7567 filesystem 6758 regex 6247 json 5989 python 5554 serialization 5177 graph 4754 log 4497 Of course it is possible that Asio is complex (as all asynchronous libraries are) and its users have a greater need to read the docs. Yet intuitively we know networking is popular so the heavier traffic is likely more reflective of the importance of networking over, say, the use of filesystem. Thanks
Em seg., 18 de ago. de 2025 às 16:28, Seth via Boost <boost@lists.boost.org> escreveu:
On Mon, Aug 18, 2025, at 9:24 PM, Seth via Boost wrote:
You don't have to ask. If you don’t, you lost on the “gaining trust” before you started.
That all said, I’m not convinced I saw the convincing reasons for forking. One repeated example was “using std::error_code and friends”. Standalone Asio already does this by default, so it would be a trivial change to split this conditional. However, the choice is on purpose (Boost System has more features than the standard library version), as pointed out by Peter Dimov before.
I’ve also seen reasonably responsive behavior from Chris, just mostly on the things he cares about. I’ve been very surprised when Emile Cormier posted his any_completion_handler (https://github.com/chriskohlhoff/asio/issues/1100) idea and Chris landed an improved version … in the next release or close to that. The subsequent work to that feature (and adjacent features like immediate executors, consign, channels etc) do suggest the value in keeping Asio development in one place.
https://github.com/chriskohlhoff/asio isn't a git repo that only accepts changes relevant to Christopher Kohlhoff. From my own experience: * Every design change proposed by the standard executors TS WG gets into ASIO eventually. This is no small amount of work, and it gets consistently done. * Every time I've reached out to improve FreeBSD support (even in niche cases), the changes were accepted (most of the times Chris rewrote the changes himself, but got the job done anyways). The only case where FreeBSD support still lags behind is a case where I haven't gotten the time to write a patch myself (nowadays I rarely contribute to ASIO as I'm spending my time elsewhere although I still use ASIO heavily a lot). I think the main problem in ASIO is a lack of clear contribution guidelines. Everytime I get a developer under my wing to do something to ASIO, I always have to explain the contribution process: * PRs are only accepted a couple of weeks prior to the next release. * Do include as much detail on why the changes you've done are important as possible in the commit messages. Get the patch right *the very first time* if you want timely responses. * You have to follow the commit history to see if your changes got accepted because most of the time Chris rewrites the patches to not delay fixes even further (instead of asking for changes and then waiting until you get the patches to his liking). The downside: you don't get automatic Github notifications when your request gets done. Just adding these guidelines in the README.md would help to clarify the ASIO contribution process and decrease frustration IMO. The process isn't perfect, but there is no perfect. Maybe someone to act as a bug triager could improve the process (e.g. fixing duplicate/invalid issues). This would save time not only for contributors who sent a patch and have to manually follow the git repo, but it'd also save Chris time as he wouldn't have to deal with the eventual lazy contributors who'd force Chris to waste time instead (as it's common in open source projects). To be completely honest, I shall also mention to the downsides that affected me in the past: * When I have multiple changes and one stacks on top of another, it takes multiple release cycles to get the whole feature-set into ASIO. Nowadays I'm no longer spending time on improving FreeBSD support for ASIO as the current model forced these changes to become a multi-year effort, and now I already moved on to a different project. -- Vinícius dos Santos Oliveira
On Mon, Aug 18, 2025 at 12:28 PM Seth via Boost <boost@lists.boost.org> wrote:
I’ve also seen reasonably responsive behavior from Chris, just mostly on the things he cares about. I’ve been very surprised when Emile Cormier posted his any_completion_handler ( https://github.com/chriskohlhoff/asio/issues/1100) idea and Chris landed an improved version … in the next release or close to that. The subsequent work to that feature (and adjacent features like immediate executors, consign, channels etc) do suggest the value in keeping Asio development in one place.
Yes, there is no question that Chris maintains his library. The problem is that there is no communication. He is unresponsive to emails, unresponsive to GitHub issues, and unresponsive to pull requests. He does not participate on the mailing list. I have to underscore that I am not proposing architectural changes in this Asio2. The primary difference between the fork and the original is that the fork will have professional maintenance folks who are responsive to emails, responsive to GitHub issues, responsive to pull requests (even if it is just to close them), and participate on the mailing list. The documentation could be evolved by a professional writing team, with improved examples. We can explore changes to make this offering more appealing to folks who have turned their backs on Boost (e.g. std::error_code). There is also the possibility of having paid support for corporate customers, donations going to support Boost and pay for maintenance. These things are not practical in the current model where the library author proceeds to ignore everyone. Thanks
On 19 Aug 2025 00:11, Vinnie Falco via Boost wrote:
On Mon, Aug 18, 2025 at 12:28 PM Seth via Boost <boost@lists.boost.org> wrote:
I’ve also seen reasonably responsive behavior from Chris, just mostly on the things he cares about. I’ve been very surprised when Emile Cormier posted his any_completion_handler ( https://github.com/chriskohlhoff/asio/issues/1100) idea and Chris landed an improved version … in the next release or close to that. The subsequent work to that feature (and adjacent features like immediate executors, consign, channels etc) do suggest the value in keeping Asio development in one place.
Yes, there is no question that Chris maintains his library. The problem is that there is no communication. He is unresponsive to emails, unresponsive to GitHub issues, and unresponsive to pull requests. He does not participate on the mailing list. I have to underscore that I am not proposing architectural changes in this Asio2. The primary difference between the fork and the original is that the fork will have professional maintenance folks who are responsive to emails, responsive to GitHub issues, responsive to pull requests (even if it is just to close them), and participate on the mailing list. The documentation could be evolved by a professional writing team, with improved examples. We can explore changes to make this offering more appealing to folks who have turned their backs on Boost (e.g. std::error_code).
I don't quite understand this. You don't want major changes in your fork but you're still going somehow to handle PRs and issues. How is that possible, other than by just closing them as "won't fix"? You can't maintain and develop the fork without making changes, sometimes major ones. And if that's not the plan, I don't see the point. Just use standalone Asio if you want std::error_code so much.
There is also the possibility of having paid support for corporate customers, donations going to support Boost and pay for maintenance. These things are not practical in the current model where the library author proceeds to ignore everyone.
This part smells badly to me. Chris is the one who's doing the bulk of the work on Asio, and I don't think it is appropriate to profit on his work.
On Mon, Aug 18, 2025 at 2:41 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
Chris is the one who's doing the bulk of the work on Asio, and I don't think it is appropriate to profit on his work.
You are suggesting that the model where organizations offer paid support for open source libraries or operating systems is inappropriate? Red Hat and Ubuntu would like a word. Thanks
On 19 Aug 2025 01:01, Vinnie Falco wrote:
On Mon, Aug 18, 2025 at 2:41 PM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
Chris is the one who's doing the bulk of the work on Asio, and I don't think it is appropriate to profit on his work.
You are suggesting that the model where organizations offer paid support for open source libraries or operating systems is inappropriate? Red Hat and Ubuntu would like a word.
I'm not a fan of what Red Hat does with their distros and the open-source software they use. They did their share of shady stuff in the past[1], so probably not a good example to bring up. But even then, CentOS and Ubuntu are free and supported for free (for their respective support periods). [1]: https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/
Everyone is making money from open source code, including each one of us. This involves a lot of code we particularly didn't write, but we also didn't just steal. I think for most people the line is crossed once open source code is sold privately, or somehow the relationship becomes parasitic, but even then it is not this black and white. We should be very cautious in framing legitimate work, sprucing up a key open source project, and charging for it, as somehow inappropriate. That's the core of open source, and boost is not a GPL project. Claudio.
On 19 Aug 2025 04:14, Claudio DeSouza via Boost wrote:
Everyone is making money from open source code, including each one of us. This involves a lot of code we particularly didn't write, but we also didn't just steal. I think for most people the line is crossed once open source code is sold privately, or somehow the relationship becomes parasitic, but even then it is not this black and white. We should be very cautious in framing legitimate work, sprucing up a key open source project, and charging for it, as somehow inappropriate. That's the core of open source, and boost is not a GPL project.
The question is what exactly is one making money on. I don't have a problem if one creates a product using open-source software and makes money on it, provided that this doesn't violate licenses and the product has value of its own. I also don't have a problem if one offers his IT or software development expertise in a domain involving third party software as a paid service. I do have a problem if one takes an existing third party library and, with little to no changes to it, starts making profit off of it. Granted, the line can be rather blurry, but the key ethical factor for me is whether there is added value in what you're selling and whether that added value is significant enough compared to the original work. Anyway, that's just my personal view.
pon., 18 sie 2025 o 23:11 Vinnie Falco via Boost <boost@lists.boost.org> napisał(a):
On Mon, Aug 18, 2025 at 12:28 PM Seth via Boost <boost@lists.boost.org> wrote:
I’ve also seen reasonably responsive behavior from Chris, just mostly on the things he cares about. I’ve been very surprised when Emile Cormier posted his any_completion_handler ( https://github.com/chriskohlhoff/asio/issues/1100) idea and Chris landed an improved version … in the next release or close to that. The subsequent work to that feature (and adjacent features like immediate executors, consign, channels etc) do suggest the value in keeping Asio development in one place.
Yes, there is no question that Chris maintains his library. The problem is that there is no communication. He is unresponsive to emails, unresponsive to GitHub issues, and unresponsive to pull requests. He does not participate on the mailing list. I have to underscore that I am not proposing architectural changes in this Asio2. The primary difference between the fork and the original is that the fork will have professional maintenance folks who are responsive to emails, responsive to GitHub issues, responsive to pull requests (even if it is just to close them), and participate on the mailing list. The documentation could be evolved by a professional writing team, with improved examples. We can explore changes to make this offering more appealing to folks who have turned their backs on Boost (e.g. std::error_code). There is also the possibility of having paid support for corporate customers, donations going to support Boost and pay for maintenance. These things are not practical in the current model where the library author proceeds to ignore everyone.
I wonder, if instead of your proposal we only addressed the documentation issue, would it sufficiently mitigate the problem that there would no longer be a need for a fork? We could leave the current ASIO docs be, but provide along it an alternative tutorial, which gently introduces the concepts, offers a lot of examples and "how you do X"s. Regards, &rzej;
On Mon, Aug 18, 2025 at 12:25 PM Seth via Boost <boost@lists.boost.org> wrote:
On Mon, Aug 18, 2025, at 6:34 PM, Artyom Beilis via Boost wrote:
IMHO if something is needed it is a lightweight object oriented alternative to asio instead of template based one when for example stream socket handles both Unix domain socket and tcp without templates. This, ironically, would be something you can propose. Far too many (bad) attempts exist in the wild-west (e.g. github). It does seem to have grown increasingly easy (the advent of any_executor, any_completion_handler, associator<Tag, …> traits), so I’m no longer as convinced of the need, but perhaps I’m the wrong target audience.
Speaking on this a bit more, I'm not entirely convinced a v2 of Asio would even need half as much of the customization points it has today. I'm actually not sure how much they're used in practice but I can say that I've kept basically all of my deployed Asio very vanilla and I've never taken advantage of any features like a custom executor. The only thing I've ever done is migrate from implicit strand to explicit strand or something along those lines. It is funny though, how even Chris seems to have realized the problems with templates and introduced the classes like `any_executor`. An Asio with far fewer templates and built entirely around coroutines would be a very compelling competitor. - Christian
Em seg., 18 de ago. de 2025 às 17:12, Christian Mazakas via Boost <boost@lists.boost.org> escreveu:
An Asio with far fewer templates and built entirely around coroutines would be a very compelling competitor.
I'd be interested in this. However I don't think this would be a direct competitor to ASIO. ASIO is interesting precisely because it's customizable so it can get integrated into projects that have wildly different needs from one another. An "ASIO" built entirely around coroutines wouldn't be far from some sort of Boost.Fiber2. The design would be massively simplified, and the only changes from Boost.Fiber would be: * Boost.Fiber1 fibers don't take IO into account, and this translates into a design that only lacks **one** feature: cancelling active fibers (IO might never finish so vocabulary to express this little need is a big deal). Meaning: if Oliver Kowalke accepts the change for adding this single feature, we don't even need Boost.Fiber2. Boost.Fiber design is stable, and stability is in itself a huge deciding factor. I don't have the time to upgrade all my ASIO-dependent projects every time ASIO breaks the API, and ASIO always breaks the API every few years. * A scheduler that takes kernel-notified IO events into consideration (e.g. Windows overlapped IO, Linux epoll & io_uring, FreeBSD kqueue, ...). -- Vinícius dos Santos Oliveira
On Mon, Aug 18, 2025 at 1:43 PM Vinícius dos Santos Oliveira via Boost < boost@lists.boost.org> wrote:
I'd be interested in this. However I don't think this would be a direct competitor to ASIO. ASIO is interesting precisely because it's customizable so it can get integrated into projects that have wildly different needs from one another.
You can have that today: https://github.com/boostorg/cobalt/blob/53611b9d322094c6fe57cdb92c257ca7240f... We can determine what kind of market exists for this product by observing its adoption. Specifically, whether it becomes more popular than Asio. Or even finding use in other open source projects. Thanks
Vinnie Falco wrote:
On Mon, Aug 18, 2025 at 1:43 PM Vinícius dos Santos Oliveira via Boost < boost@lists.boost.org> wrote:
I'd be interested in this. However I don't think this would be a direct competitor to ASIO. ASIO is interesting precisely because it's customizable so it can get integrated into projects that have wildly different needs from one another.
You can have that today:
https://github.com/boostorg/cobalt/blob/53611b9d322094c6fe57cdb92c257ca7240f...
The problem with that is this: https://github.com/boostorg/cobalt/blob/53611b9d322094c6fe57cdb92c257ca7240f...
On Mon, Aug 18, 2025 at 4:26 PM Peter Dimov <pdimov@gmail.com> wrote:
The problem with that is this:
https://github.com/boostorg/cobalt/blob/53611b9d322094c6fe57cdb92c257ca7240f...
That's just an implementation detail which can be changed without affecting Cobalt's API Thanks
On Mon, Aug 18, 2025 at 5:31 PM Vinnie Falco via Boost < boost@lists.boost.org> wrote:
On Mon, Aug 18, 2025 at 1:43 PM Vinícius dos Santos Oliveira via Boost < boost@lists.boost.org> wrote:
I'd be interested in this. However I don't think this would be a direct competitor to ASIO. ASIO is interesting precisely because it's customizable so it can get integrated into projects that have wildly different needs from one another.
You can have that today:
https://github.com/boostorg/cobalt/blob/53611b9d322094c6fe57cdb92c257ca7240f...
We can determine what kind of market exists for this product by observing its adoption. Specifically, whether it becomes more popular than Asio. Or even finding use in other open source projects.
Not surprisingly, I think this is the way to go: create more particular networking libraries on top of asio, e.g. one for boost.fiber or one based on a future library etc. And based issues arising from those you can propose solutions to Chris'. Another area would be buffers, and your library does work on that, too. A major theme I am observing with many PRs for asio, is that they don't look at the bigger picture. There are very few people who are able to do that with a complex problem domain like networking. That is why Chris is just cherry-picking as he sees fit and is often adopting ideas into his own constructs. He is maintaining his library and there is no requirement for him to collaborate or interact with anybody. I think he's doing the right thing based on the PRs he usually gets. I find it generally distasteful when people feel they're entitled to someone's time/attention because they're using something they got for free.
Thanks _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/OKWDDB55...
Actually, am I reading this thread correctly in that Chris doesn't accept PRs, he just copy-paste-edits the code into no longer being a copyright infringement and then merges it himself into develop? I'm thinking that I must've read it wrong. Also, writing a scheduler that just manages concurrent I/O isn't _that_ hard and it would not justify that kind of behavior. - Christian
Christian Mazakas wrote:
Actually, am I reading this thread correctly in that Chris doesn't accept PRs, he just copy-paste-edits the code into no longer being a copyright infringement and then merges it himself into develop?
It's hard to tell from the outside, but I don't think Chris ever copy-pastes anything. That's been his policy from day one; he only commits code himself. Before the move to Github this wasn't an issue because there was no way to submit a PR anyway. You can disable issues on Github, but not PRs, or I'd expect him to have done so.
On Tue, Aug 19, 2025 at 11:38 AM Peter Dimov via Boost < boost@lists.boost.org> wrote:
Christian Mazakas wrote:
Actually, am I reading this thread correctly in that Chris doesn't accept PRs, he just copy-paste-edits the code into no longer being a copyright infringement and then merges it himself into develop?
It's hard to tell from the outside, but I don't think Chris ever copy-pastes anything.
That's been his policy from day one; he only commits code himself. Before the move to Github this wasn't an issue because there was no way to submit a PR anyway.
You can disable issues on Github, but not PRs, or I'd expect him to have done so.
I understand not wanting to accept contributions because no one can code as well as you can, even for arbitrary reasons. A concurrent I/O runtime is an incredibly complex beast and I wouldn't expect most developers to meet the burden of testing required for ensuring that a change is sound. But that's not what's happening, it seems. It seems like contributors are learning Asio well enough to have meaningful PRs, which Chris then just uses as a reference and then commits himself. This isn't exactly "illegal", but I do believe it flies in the face of the values that Boost should embody. There is no mandate that an author accept a contribution they don't want, but it's different when someone makes a PR and you simply re-author it yourself using them as a reference. --- I wrote the above before checking GH for copyright attribution. After having checked boostorg/asio, there are a few files where Klemens and Rep Invariant Systems were given attribution. There were also single-file contributions from Voipster and Oliver Kowalke. For the above reasons, I think an Asio fork would actually be a really wise decision. An Asio fork could stand and serve as a better embodiment of Boost's values. Therefore: huge +1 to Asio fork idea. - Christian
On Tue, Aug 19, 2025 at 1:41 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
I understand not wanting to accept contributions because no one can code as well as you can, even for arbitrary reasons.
Meanwhile, the actual reason that Crhis does not accept contributions is because it can put his clients at legal risk.That is why he does very rarely accept PRs from particular individuals (such as Klemens). Thanks
On Tue, Aug 19, 2025 at 2:07 PM Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Tue, Aug 19, 2025 at 1:41 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
I understand not wanting to accept contributions because no one can code as well as you can, even for arbitrary reasons.
Meanwhile, the actual reason that Crhis does not accept contributions is because it can put his clients at legal risk.That is why he does very rarely accept PRs from particular individuals (such as Klemens).
I'm not sure this tracks, if I'm being honest. Do you have a source for this? On first glance, it doesn't make sense because the licensing isn't affected and then what's more, it's up to the consumer to trust the author (and what they merge) anyway. I don't see any legal liability or risk here. - Christian
On Tue, Aug 19, 2025, at 10:40 PM, Christian Mazakas via Boost wrote:
But that's not what's happening, it seems. It seems like contributors are learning Asio well enough to have meaningful PRs, which Chris then just uses as a reference and then commits himself.
For the above reasons, I think an Asio fork would actually be a really wise decision
Just to be clear, “the above reasons” are that you suspect Chris is copying other people’s homework. I think you need to show specific examples, because I don’t think I’ve seen any example where this would be a fair characterization. Seth
Just to be clear, “the above reasons” are that you suspect Chris is copying other people’s homework. I think you need to show specific examples, because I don’t think I’ve seen any example where this would be a fair characterization.
I'm also a bit confused about this, because there seems to be conflicting statements even in this thread. Vinnicius early, whilst praising Chris policy, said: "Every time I've reached out to improve FreeBSD support (even in niche cases), the changes were accepted (most of the times Chris rewrote the changes himself, but got the job done anyways)." And "You have to follow the commit history to see if your changes got accepted because most of the time Chris rewrites the patches to not delay fixes even further (instead of asking for changes and then waiting until you get the patches to his liking)." So I'm not sure how to interpret that, and other Asio contributors could better explain what normally happens in these cases.
ASIO is too complicated for mere mortals with too many gotchas. I dont need a ten ways to do the same thing. I just need something that works correctly without trying too hard to understand and avoid all the trip-wires and land mines that seem to repeatedly cause potential users trouble. IMO, leave ASIO alone, and build new libraries that use it but hidden and most importantly cover 90% of the normal use cases correctly. On 8/20/25 5:40 AM, Claudio DeSouza via Boost wrote:
Just to be clear, “the above reasons” are that you suspect Chris is copying other people’s homework. I think you need to show specific examples, because I don’t think I’ve seen any example where this would be a fair characterization.
I'm also a bit confused about this, because there seems to be conflicting statements even in this thread. Vinnicius early, whilst praising Chris policy, said:
"Every time I've reached out to improve FreeBSD support (even in niche cases), the changes were accepted (most of the times Chris rewrote the changes himself, but got the job done anyways)."
And
"You have to follow the commit history to see if your changes got accepted because most of the time Chris rewrites the patches to not delay fixes even further (instead of asking for changes and then waiting until you get the patches to his liking)."
So I'm not sure how to interpret that, and other Asio contributors could better explain what normally happens in these cases. _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/3X4L35UE...
On Wed, Aug 20, 2025 at 3:40 AM Claudio DeSouza via Boost < boost@lists.boost.org> wrote:
Just to be clear, “the above reasons” are that you suspect Chris is copying other people’s homework. I think you need to show specific examples, because I don’t think I’ve seen any example where this would
be a
fair characterization.
I'm also a bit confused about this, because there seems to be conflicting statements even in this thread. Vinnicius early, whilst praising Chris policy, said:
"Every time I've reached out to improve FreeBSD support (even in niche cases), the changes were accepted (most of the times Chris rewrote the changes himself, but got the job done anyways)."
And
"You have to follow the commit history to see if your changes got accepted because most of the time Chris rewrites the patches to not delay fixes even further (instead of asking for changes and then waiting until you get the patches to his liking)."
Yeah, this is exactly what I'm alluding to. Fwiw, I'm not saying that absolutely Chris is infringing on copyright or anything like that. But what I'm hearing does sound kind of suspicious. It's not "illegal" (for some colloquial definition of bad behavior), but it does sound kind of scummy/suspicious to me. And for this reason, it seems to me like an Asio fork maintained by those who zealously love it so much would be a major improvement because it sounds like the goal is to better embody the actual values of Boost and open-source collaboration. - Christian
On Wed, Aug 20, 2025, 10:50 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
On Wed, Aug 20, 2025 at 3:40 AM Claudio DeSouza via Boost < boost@lists.boost.org> wrote:
Just to be clear, “the above reasons” are that you suspect Chris is copying other people’s homework. I think you need to show specific examples, because I don’t think I’ve seen any example where this would
be a
fair characterization.
I'm also a bit confused about this, because there seems to be conflicting statements even in this thread. Vinnicius early, whilst praising Chris policy, said:
"Every time I've reached out to improve FreeBSD support (even in niche cases), the changes were accepted (most of the times Chris rewrote the changes himself, but got the job done anyways)."
And
"You have to follow the commit history to see if your changes got accepted because most of the time Chris rewrites the patches to not delay fixes even further (instead of asking for changes and then waiting until you get the patches to his liking)."
Yeah, this is exactly what I'm alluding to.
Fwiw, I'm not saying that absolutely Chris is infringing on copyright or anything like that. But what I'm hearing does sound kind of suspicious.
It's not "illegal" (for some colloquial definition of bad behavior), but it does sound kind of scummy/suspicious to me.
Please stop making unbased, slanderous allegations on the mailing list. Thank you.
On Wed, Aug 20, 2025 at 9:50 AM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
On Wed, Aug 20, 2025 at 3:40 AM Claudio DeSouza via Boost < boost@lists.boost.org> wrote:
Just to be clear, “the above reasons” are that you suspect Chris is copying other people’s homework. I think you need to show specific examples, because I don’t think I’ve seen any example where this would
be a
fair characterization.
I'm also a bit confused about this, because there seems to be conflicting statements even in this thread. Vinnicius early, whilst praising Chris policy, said:
"Every time I've reached out to improve FreeBSD support (even in niche cases), the changes were accepted (most of the times Chris rewrote the changes himself, but got the job done anyways)."
And
"You have to follow the commit history to see if your changes got accepted because most of the time Chris rewrites the patches to not delay fixes even further (instead of asking for changes and then waiting until you get the patches to his liking)."
Yeah, this is exactly what I'm alluding to.
Fwiw, I'm not saying that absolutely Chris is infringing on copyright or anything like that. But what I'm hearing does sound kind of suspicious.
It's not "illegal" (for some colloquial definition of bad behavior), but it does sound kind of scummy/suspicious to me.
As a counter-example.. When I created the modular build PR to the *Boost* ASIO repo Chris "rewrote" it to fit the standalone ASIO structure and mirror process in due time. And, yes, I only realized he had implemented it by watching the results of repo instead of the PR itself. More apropos to the above comment.. Chris kept my copyright notice in the PR. Something I'vé observed through handling PRs across various repos is that people just about never update the copyright info when creating PRs (they also rarely add or adjust tests). Hence I don't fault Chris in this respect. As it's more expedient to assume that the creator of the PR in such cases that they intend to disclaim any substantial copyright on their proposed change. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net
Em qua., 20 de ago. de 2025 às 07:41, Claudio DeSouza via Boost <boost@lists.boost.org> escreveu:
I'm also a bit confused about this, because there seems to be conflicting statements even in this thread. Vinnicius early, whilst praising Chris policy, said:
"Every time I've reached out to improve FreeBSD support (even in niche cases), the changes were accepted (most of the times Chris rewrote the changes himself, but got the job done anyways)."
And
"You have to follow the commit history to see if your changes got accepted because most of the time Chris rewrites the patches to not delay fixes even further (instead of asking for changes and then waiting until you get the patches to his liking)."
So I'm not sure how to interpret that, and other Asio contributors could better explain what normally happens in these cases.
I'm sorry for my lack of clarity. My point was that ASIO is *not* just a helper tool for Chris' personal work. Changes to ASIO unrelated to Chris' daily work do get accepted into ASIO. I developed a project similar to NodeJS (but using Lua instead of JS) that uses ASIO. My project was somewhat ambitious and can do things that the JS community won't ever do (e.g. suid binaries, containers and sandboxes w/o relying on 3rd party runtimes). As part of this work, I needed tight integration with many UNIX details that I'm sure Chris doesn't care about in his daily work, but merged the changes I requested anyway (e.g. avoiding FIONBIO on assigned file descriptors as ioctl are dangerous if you're handling a resource received from a sandbox). That's the first point: Chris accepts changes that don't affect his daily work (even when they're debatably niche cases). Now to the second point: he does rewrite a lot of the patches you send. I wrote/submitted a number of patches, but only 3 got accepted as-is. Implementation-wise, the rewritten code didn't lose anything to my implementation (usually they're equivalent or superior taking many more ASIO internals into account). Commit history-wise, my commit messages were better and explained problems in minute detail. I wouldn't mind if he instead copy-paste'd my commit messages as it'd better record why the changes are necessary. A bit more clarification about one of the experiences I shared earlier: I did spend time writing patches to improve FreeBSD support in the past. FreeBSD support improved, but not sufficiently. There are still 2 changes -- one small and one medium -- to have FreeBSD on par with other platforms. I actually managed to persuade FreeBSD devs to add new functions in the base system to better accommodate ASIO needs (e.g. aio_read2) so it's a bit of a shame that ASIO isn't still using them. However I'm no longer actively working on improving ASIO. I moved to other stuff (although I'm still a heavy ASIO user) and I won't be writing patches to further improve FreeBSD support (reach out to me if you're interested; I still would be willing to mentor if someone else is the one doing the heavy work). -- Vinícius dos Santos Oliveira
On Wed, Aug 20, 2025 at 8:02 AM Vinícius dos Santos Oliveira via Boost < boost@lists.boost.org> wrote:
Now to the second point: he does rewrite a lot of the patches you send. I wrote/submitted a number of patches, but only 3 got accepted as-is. Implementation-wise, the rewritten code didn't lose anything to my implementation (usually they're equivalent or superior taking many more ASIO internals into account). Commit history-wise, my commit messages were better and explained problems in minute detail. I wouldn't mind if he instead copy-paste'd my commit messages as it'd better record why the changes are necessary.
This actually seems to kinda back up what I was alluding to earlier. In these scenarios, does Chris make sure to add comments saying that you were the original progenitor of these ideas/contributions? Or does he just rewrite your patches and not update the copyright notices? While this kind of stuff isn't exactly wrong in a strict legal sense, I don't think it's a good thing by any measure. People deserve credit for the things they fix and notice. For example, the Linux kernel will often include a "Reported-by" in the commit message that gives credit to the person who discovered the bug. - Christian
On Wed, Aug 20, 2025, at 12:40 PM, Claudio DeSouza via Boost wrote:
So I'm not sure how to interpret that, and other Asio contributors could better explain what normally happens in these cases.
That is not the question. The first question is whether we understand what’s actually happening under these descriptions. Your question appears to silently accept the premise that we interpret correctly what is happening, anyways. E.g. in the case of that any_completion_handler PR I think it got paired up with a considerable revamp of the associator traits (although I might suffer from hazy memory and merely remember these changes occurring around the same release). A lot of the time Chris sees a change request as a reason to improve implementation details, often with large impact outside the feature at hand. It would not be practical/fair/possible to require a contributor to redo their feature/change to fit the new plumbing. Another example I remember is Klemens’ idea to make error_code& a completion token per se, so c++20 syntax would not be burdened at all. Some 5-10 releases down the road we not only have a general family of token adapters (consign, as_tuple, redirect_error, cancel_after…) but even a default completion token that changed to default to asio::deferred_t. All in all, not only does redirect_error(ec) more or less do exactly what Klemens’ idea sketched, but we got the far superior solution where c++20 co_await syntax has the best of all worlds regardless of how errors are handled. This is not an example that started with concrete code by Klemens (if memory serves) but it sure serves as an example how the concrete ideas inspire re-imagined solutions rather than verbatim contributions. Again, if we’re gonna stage an investigation into perceived plagiary or use of work without credit, that seems both a derailment of the topic (so warrants its own thread) and requires tangible examples. Seth
Your question appears to silently accept the premise that we interpret correctly what is happening, anyways.
My question certainly doesn't suggest that. I asked a question based on discussions in this thread for which I provided a quote, to which Vinnicius answered, but somehow you are sidestepping the conversation. All that you are doing is being hostile to anyone you perceive as an enemy in your head, without any engagement to what is being actually brought up, which in my case was less than nothing. Claudio.
On Thu, Aug 21, 2025, at 1:53 AM, Claudio DeSouza via Boost wrote:
Your question appears to silently accept the premise that we interpret correctly what is happening, anyways.
My question certainly doesn't suggest that. I asked a question based on discussions in this thread for which I provided a quote, to which Vinnicius answered, but somehow you are sidestepping the conversation.
I said “your question” (not “you”) and “appears to accept” (not “accepts”). I didn’t assume it was what you intended. Yes, that was my subjective read, and it might be “wrong”.
All that you are doing is being hostile to anyone you perceive as an enemy in your head, without any engagement to what is being actually brought up, which in my case was less than nothing.
Well. Again it <appears> you are projecting. Also, you ignore the substantial, on-topic examples that I took time to write up. In case I misunderstood your intent, my apology. I don’t think your response was fair in any way. We can be civil even if we misunderstand - or even when people *are* hostile.
Claudio.
In case I misunderstood your intent, my apology.
I accept your apology. I don’t think your response was fair in any way. We can be civil even if we
misunderstand - or even when people *are* hostile.
I have been civil, and Vinnicius did reply to my inquiry with no problem. You somehow had to misrepresent what I said to object to it. This thread is about whether or not to fork Asio. People are trying to understand what are the problems with it, and how having a fork will help boost and C++ overall. Nearly every healthy project gets forked (with exception of git), and it is necessary to have some frankness of speech to discuss the gripes and "grievances" (for a lack of better word) that people may have with any given project. This is not an attack to the honour of the original author. It is rather the very function of the whole open source endeavour. No single author is expected to abide by a set of rules, but communities are also allowed to discuss alternative approaches to certain projects. Claudio.
Heads up: largely off topic: On Sat, Aug 23, 2025, at 2:50 AM, Claudio DeSouza via Boost wrote:
I have been civil
You said "All that you are doing is being hostile to anyone you perceive as an enemy in your head, without any engagement to what is being actually brought up, which in my case was less than nothing." That is not civil. Also, you don't know me, so how could you reach those conclusions?
This thread is about whether or not to fork Asio. People are trying to understand what are the problems with it, and how having a fork will help boost and C++ overall. Nearly every healthy project gets forked (with exception of git), and it is necessary to have some frankness of speech to discuss the gripes and "grievances" (for a lack of better word) that people may have with any given project. This is not an attack to the honour of the original author. It is rather the very function of the whole open source endeavour. No single author is expected to abide by a set of rules, but communities are also allowed to discuss alternative approaches to certain projects.
I whole-heartedly agree with most of that. I *do* feel Chris M was attacking Chris K. for his lack [or method of] attribution. There are ways outside VCS commit authorship. My message was describing how I've seen it play out and how it makes sense (to me). It's not about "enemies" to me. It's about understanding what is actually happening, not a simplistic representation. You never even acknowledge any of that. Instead you posted the above personal attack adding "[I] didn't [engage] to what is being actually brought up". Did you mean to say: "in a way I expected or, understood or wanted"? Let me be clear. It would be okay if nobody understood what I was trying to say. That happens. It's also fine if [you think] my anecdotes were irrelevant to community values. Just say so. It's not okay (or productive, or required) to make people miserable about it. Just don't be a dick. ----- You're right that others have found better words, and especially Vinícius' experience/testimony helped put things in better perspective. Arnaud seems to have the communicative skill to actually get to the matter. Much respect. I hope we can all learn over time. For me, I'll lay low or drop off the list again for a few years. It seems to work out better that way. To anyone still reading, apologies for wasting our time. Regards, Seth
You're right that others have found better words, and especially Vinícius' experience/testimony helped put things in better perspective. Arnaud seems to have the communicative skill to actually get to the matter. Much respect.
I hope we can all learn over time.
For me, I'll lay low or drop off the list again for a few years. It seems to work out better that way. To anyone still reading, apologies for wasting our time.
That sucks, your opinion is valued. Vinnie, Christian M. and Claudio have however vindicated Chris K.'s policy of not engaging.
Regards, Seth _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/GBTXUQTI...
On Fri, Aug 22, 2025 at 9:07 PM Klemens Morgenstern via Boost < boost@lists.boost.org> wrote:
Vinnie, Christian M. and Claudio have however vindicated Chris K.'s policy of not engaging.
You know, I've been thinking about this. Back when I was working on my io_uring stuff in C++, I'd think a lot about how nice it would've been to have Chris' participation on something like the ML to help me develop it. I think about all the questions I could've asked him, all the wisdom he could've shared with me. What's more, Chris is the _only_ person in the entirety of Boost who would've been qualified to manage the review, had I submitted the library to Boost. In my experience, most of the self-proclaimed "networking experts" in C++ have actually no interest in io_uring, which is disappointing because it's where all of the innovation is happening. And I just can't help but think if that tune would've changed in Boost had Chris stepped in once and said, "Hey, this is a cool project". But alas, such is life. Because of all this, I think I prove that Chris loses a tremendous amount by not participating in Boost. There's really only so many of us runtime authors and Boost could've had something really, really cool in it. Obligatory link: https://github.com/cmazakas/fiona - Christian
On Sun, Aug 24, 2025, 9:21 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
On Fri, Aug 22, 2025 at 9:07 PM Klemens Morgenstern via Boost < boost@lists.boost.org> wrote:
Vinnie, Christian M. and Claudio have however vindicated Chris K.'s policy of not engaging.
You know, I've been thinking about this.
Back when I was working on my io_uring stuff in C++, I'd think a lot about how nice it would've been to have Chris' participation on something like the ML to help me develop it. I think about all the questions I could've asked him, all the wisdom he could've shared with me. What's more, Chris is the _only_ person in the entirety of Boost who would've been qualified to manage the review, had I submitted the library to Boost.
In my experience, most of the self-proclaimed "networking experts" in C++ have actually no interest in io_uring, which is disappointing because it's where all of the innovation is happening. And I just can't help but think if that tune would've changed in Boost had Chris stepped in once and said, "Hey, this is a cool project". But alas, such is life.
Because of all this, I think I prove that Chris loses a tremendous amount by not participating in Boost. There's really only so many of us runtime authors and Boost could've had something really, really cool in it.
I don't understand, what did Chris lose out on? Helping you?
Obligatory link: https://github.com/cmazakas/fiona
- Christian _______________________________________________ Boost mailing list -- boost@lists.boost.org To unsubscribe send an email to boost-leave@lists.boost.org https://lists.boost.org/mailman3/lists/boost.lists.boost.org/ Archived at: https://lists.boost.org/archives/list/boost@lists.boost.org/message/SQRVDBUE...
Klemens Morgenstern wrote:
On Sun, Aug 24, 2025, 9:21 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
Because of all this, I think I prove that Chris loses a tremendous amount by not participating in Boost. There's really only so many of us runtime authors and Boost could've had something really, really cool in it.
I don't understand, what did Chris lose out on? Helping you?
He lost the opportunity to be accused of stealing people's code.
I hope we can all learn over time.
Seth, I think we both got a bit carried away on this thread. I'm not gonna start addressing the point by point above because there's no benefit, and enough has already been clarified. I apologise that communication went in this direction. Claudio
On Fri, Aug 22, 2025 at 8:53 PM Seth via Boost <boost@lists.boost.org> wrote:
For me, I'll lay low or drop off the list again for a few years. It seems to work out better that way. To anyone still reading, apologies for wasting our time.
See, I think this is the wrong takeaway. People are always bound to miscommunicate, emotions get high, etc. I think turning around and saying, "I just shouldn't participate" is the wrong takeaway from all of this. Just walk it off. - Christian
I tried to stay out of this discussion, since it seems pointless, but stakes are too high so... On Sun, Aug 24, 2025 at 3:38 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
See, I think this is the wrong takeaway.
People are always bound to miscommunicate, emotions get high, etc.
I think turning around and saying, "I just shouldn't participate" is the wrong takeaway from all of this. Just walk it off.
When emotions run high, that’s a reason to step back before posting, not to flood the mailing list with rants. Expert time is precious. For example I am sure that Jonathan Wakely has infinite amount of tasks to do, and for people to waste his time with random rants is not productive. So no I do not accept that people can behave inappropriately on the ML even ignoring the fact that polite communication should be mandated. When quality of discussion drops it is more likely people will stop reading. So although I know 99.9% I will be ignored here is my suggestion: Instead of reading Chris mind and guessing Alliance could have asked Chris and offered to provide funding, e.g. 1. If Chris does not have enough time to do all the work on ASIO due to his regular work it would probably more effective to hire him to work on lower priority issues, than to deal with the fork. This depends on the fact that Chris would be willing to hired, many people find their OS work relaxation from work and would not accept this setup, but you could have asked before asking ML about forking. 2. If Chris does not want to accept commits from others because he fears contamination/legal issues you could have talked to Chris if there is any way to solve this, e.g. if a person committing code signed a contract with Alliance and guarantees all code committed is his own work, not copied from some GPL source. 3. If Chris trust some contributors enough to prune/prioritize issues/PRs Alliance could have offered to fund that so Chris throughput is increased. I do not know Chris so maybe he would have rejected all proposals(Googling I learned that Chris rejected to be hired by Alliance 8 years ago, kind of shows the quality of discussion here: almost 100 messages and I had to Google this)... but I have seen no proof of this, just people guessing. Additionally I think the demands you place on Chris are unreasonable. He maintains ASIO for 10+ years. Sure he could do more. But you know who could also do more? Tens/hundreds of people who are experts in same areas as Chris, but do not participate in Boost or open source at all. Maybe framing it like this will help you understand how much Chris work did for free for the C++/Boost. It is hard to estimate impact of certain library since we do not know alternative timeline(would somebody came up with ASIO like library few months later if Chris did not) but I would not be surprised if Chris work resulted in hundreds of millions or even billions in savings for all the users of ASIO who got a much better library(with documentation) compared to what they would get if they did it themselves. To be clear: I understand the frustration that ASIO seems understaffed (and I think most people here agree it could move faster). But forking looks like the worst way forward. A better option is to ask Chris what kind of support he would actually accept, instead of endlessly speculating. In unlikely case Chris reads this I would ask him to just consider that maybe ASIO became too big of a project to be maintained by just 1 person, even if that person is extremely talented. P.S. I could go more deeply why some of speculation about Chris motivations does not make sense, but as I consider that kind of discussions pointless I do not want to add to this useless direction.
On Sun, Aug 24, 2025 at 8:05 AM Ivan Matek via Boost <boost@lists.boost.org> wrote:
...it would probably more effective to hire him
The original motivation for creating The C++ Alliance was to hire Christopher Kohlhoff so he could work on Networking TS full time. He turned down the offer, explaining that having more time would not necessarily translate into more progress, because he likes to "think about things for a long time before committing to any implementation." And also that he likes to interact with his stakeholders face to face (i.e. in an office).
Googling I learned that Chris rejected to be hired by Alliance 8 years ago
Yes, this is correct.
To be clear: I understand the frustration that ASIO seems understaffed (and I think most people here agree it could move faster). But forking looks like the worst way forward. A better option is to ask Chris what kind of support he would actually accept, instead of endlessly speculating.
I agree. Have you emailed him? Or perhaps just open an issue here: https://github.com/chriskohlhoff/asio/issues Thanks
On Wed, Aug 20, 2025 at 2:20 PM Seth via Boost <boost@lists.boost.org> wrote:
E.g. in the case of that any_completion_handler PR I think it got paired up with a considerable revamp of the associator traits (although I might suffer from hazy memory and merely remember these changes occurring around the same release). A lot of the time Chris sees a change request as a reason to improve implementation details, often with large impact outside the feature at hand. It would not be practical/fair/possible to require a contributor to redo their feature/change to fit the new plumbing.
Another example I remember is Klemens’ idea to make error_code& a completion token per se, so c++20 syntax would not be burdened at all. Some 5-10 releases down the road we not only have a general family of token adapters (consign, as_tuple, redirect_error, cancel_after…) but even a default completion token that changed to default to asio::deferred_t. All in all, not only does redirect_error(ec) more or less do exactly what Klemens’ idea sketched, but we got the far superior solution where c++20 co_await syntax has the best of all worlds regardless of how errors are handled. This is not an example that started with concrete code by Klemens (if memory serves) but it sure serves as an example how the concrete ideas inspire re-imagined solutions rather than verbatim contributions.
Again, if we’re gonna stage an investigation into perceived plagiary or use of work without credit, that seems both a derailment of the topic (so warrants its own thread) and requires tangible examples.
Yeah, that's all well and good but I still think Chris could improve this dramatically here. I'm not sure if you've ever contributed to a large successful open-source project with tons of contributors, but the Linux kernel, for example, goes very much out of its way to credit people for their ideas, suggestions and bug finds. For example, I'm an early adopter of many io_uring features and I've authored the most sophisticated open-source io_uring runtime in both Rust and C++, though nowadays it's mostly Rust. You should check it out here: https://github.com/cmazakas/fiona-rs Because of this, you can see my name in the Linux commit messages: https://github.com/search?q=repo%3Atorvalds%2Flinux+%22mazakas%22&type=commi... Let's do the same for Vinicius... https://github.com/search?q=repo%3Achriskohlhoff%2Fasio+%22Oliveira%22&type=... Zero results. In general, I think it's absolutely fine for authors to take work and make it actually good for their projects. We want this to happen, actually. But we must also remember credit where it is due, and it seems like Chris does not have a good track record of this. I'm not saying this means he's plagiarizing but I do think it means a fork has value in that we can just genuinely be better open-source developers with the fork. People deserve attribution. - Christian
On Thu, Aug 21, 2025 at 7:22 AM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
Chris could improve this dramatically here.
Yes, for example: https://original.boost.org/doc/libs/1_89_0/doc/html/boost_asio/reference/asy... High quality documentation, that is. How many years has async_initiate been in Asio? Emails and GitHub issues go unanswered. Who is going to bother doing the work for a PR without some kind of assurance that there will be an interaction? This entire thread is going in a very predictable direction where everyone explains why a fork is a bad idea and suggests that people write new things which are not forks, yet there is nothing actionable to solve the fundamental problem which is that we have a perfectly working and well maintained library yet the aspects where it interfaces with the public are utterly lacking. My proposed solution is a fork and the only other answer which addresses the stated problem has been "its fine the way it is" (and this is most certainly incorrect, see link above). Thanks
Chris could improve this dramatically here.
Yes, for example:
https://original.boost.org/doc/libs/1_89_0/doc/html/boost_asio/reference/asy...
High quality documentation, that is. ... My proposed solution is a fork and the only other
Maybe the discussion should be not how to fork - the logical answer is obvious - why do you think another maintainer will do the better job. The discussion should be how to help improve code and documentation of ASIO when the author is busy? See the difference? Instead of going negative-counter-productive way - see how can it be "how community can help" Now than it is something that can be discussed with maintainer on higher level and maybe co-developer/development team can be created to manage some of the issues. Fork - not cooperative Co-maintaining - cooperative Just $0.02 Best, Artyom
On Fri, Aug 22, 2025 at 3:13 AM Artyom Beilis via Boost < boost@lists.boost.org> wrote:
why do you think another maintainer will do the better job. The discussion should be how to help improve code and documentation of ASIO when the author is busy?
It would be paid C++ Alliance staff, and any volunteers (if there are any). The difference here is the guarantee of responsiveness. For example, look at this beautiful table explaining the type requirements for ConstBufferSequence: https://boost.org/doc/libs/1_65_0/doc/html/boost_asio/reference/ConstBufferS... And now look at the newer version: https://boost.org/doc/libs/1_66_0/doc/html/boost_asio/reference/ConstBufferS... One can no longer figure out how to meet the type requirements based on these "improved" docs. This page is objectively worse and we have no path for fixing it. Thanks
On Fri, Aug 22, 2025 at 3:13 AM Artyom Beilis via Boost < boost@lists.boost.org> wrote:
...it is something that can be discussed with maintainer...
LOL another comedian! First Andrey and now you! Yes Artyom, yes... please "discuss" this with the Asio maintainer :) Let me know the result. Thanks
On Fri, Aug 22, 2025 at 10:55 AM Vinnie Falco via Boost < boost@lists.boost.org> wrote:
On Fri, Aug 22, 2025 at 3:13 AM Artyom Beilis via Boost < boost@lists.boost.org> wrote:
...it is something that can be discussed with maintainer...
LOL another comedian! First Andrey and now you! Yes Artyom, yes... please "discuss" this with the Asio maintainer :) Let me know the result.
It is absolutely inexplicable why anyone would ever even consider ignoring your emails.
Great idea! I think you should email Chris and ask him how he feels about this. Let us know the response.
Great idea :) I’ve gone ahead and sent Chris an email to ask for his thoughts. I am aware the chances of a reply are slim :) I also understand that some of you may feel your patience is already stretched when it comes to communication and collaboration with Chris. Maybe the wider community needs to share a bit of that experience before agreeing with stronger measures like a forked takeover. Kind regards, Arno
On Fri, Aug 22, 2025, 17:07 Arnaud Becheler via Boost <boost@lists.boost.org> wrote:
Maybe the wider community needs to share a bit of that experience before agreeing with stronger measures like a forked takeover.
"Forked takeover" is a very bad way to characterize a community fork. There are many forked open source projects out there that coexist and even motivate each other to improve. If and when a fork manages to supersede the root project, it's because it has done something better and that outcome is for the best. Forking is a part of the beauty of open source and it allows projects to survive and evolve.
On Fri, Aug 22, 2025 at 5:53 PM Vinnie Falco <vinnie.falco@gmail.com> wrote:
On Fri, Aug 22, 2025 at 3:13 AM Artyom Beilis via Boost <boost@lists.boost.org> wrote:
...it is something that can be discussed with maintainer...
LOL another comedian! First Andrey and now you! Yes Artyom, yes... please "discuss" this with the Asio maintainer :) Let me know the result.
Thanks
You know, "if you want to shoot, shoot, don't talk" If you think you can create and maintain something better - start, create an alternative fork, maintain it for a year, make sure you integrate the latest fixes from main ASIO. And let's see how it goes. I clearly understand why you want to do it. But what is needed is proof that it would actually work better than the original. There are plenty of cases in the community, some more successful and some less so: MariaDB, LibreOffice, Xorg, Firefox. But there are millions of forks that never become something useful and real. So instead of talking, start working on your fork. And maybe it would actually make the ASIO maintainer realize that he needs a better way of working and solving problems or you'll create something new and better. Time will tell. But so far, all I hear is talking... As an open-source developer who has managed several projects in the past and in the present, what I hear 99% of time is talking and rarely valuable contributions. Best, Artyom
On Fri, Aug 22, 2025 at 12:17 PM Artyom Beilis via Boost < boost@lists.boost.org> wrote:
There are plenty of cases in the community, some more successful and some less so: MariaDB, LibreOffice, Xorg, Firefox. But there are millions of forks that never become something useful and real.
I would like to point out another such example that may be rather relevant.. https://github.com/bfgroup/Lyra -- I tried for some time to get PRs accepted into the original (https://github.com/catchorg/Clara). I even talked to Phil a couple of times about the changes, in person. But even with promises of Phil workin on it nothing ever happened. Hence, I decided to just fork the library. And not only applied my changes, but at this point have rewritten much of it while keeping back compatibility for the core functionality. TO the point that the original project is now explicitly no longer maintained and refers to the new fork as the canonical library. It goes to show that there is some valid impetus for creating forks. The question in the ASIO case is when is "enough is enough" to take the fork in the road? And honestly, I don't have an answer. So instead of talking, start working on your fork. But indeed, the only way to find out is to take the fork in the road. I do grant that this case is very much more complicated. And there are many questions as to what such an ASIO fork means to the Boost collection. Would it be a fork of the standalone ASIO? Would it be only a Boost version? How to synchronize with Chris' ASIO? Should it synchronize? How far would it diverge before you give in and stop trying to merge Chris' ASIO changes? Do you keep trying to upstream changes? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net
On 22 Aug 2025 09:10, Vinnie Falco via Boost wrote:
On Thu, Aug 21, 2025 at 7:22 AM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
Chris could improve this dramatically here.
Yes, for example:
https://original.boost.org/doc/libs/1_89_0/doc/html/boost_asio/reference/asy...
High quality documentation, that is. How many years has async_initiate been in Asio? Emails and GitHub issues go unanswered. Who is going to bother doing the work for a PR without some kind of assurance that there will be an interaction? This entire thread is going in a very predictable direction where everyone explains why a fork is a bad idea and suggests that people write new things which are not forks, yet there is nothing actionable to solve the fundamental problem which is that we have a perfectly working and well maintained library yet the aspects where it interfaces with the public are utterly lacking. My proposed solution is a fork and the only other answer which addresses the stated problem has been "its fine the way it is" (and this is most certainly incorrect, see link above).
The discussion showed that at least some issues and PRs are handled. Did you or anyone else try submitting a PR adding the missing documentation?
On Fri, Aug 22, 2025 at 4:14 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
The discussion showed that at least some issues and PRs are handled. Did you or anyone else try submitting a PR adding the missing documentation?
LOL Andrey! You're trolling me, right? Did you not read what I just said?
Who is going to bother doing the work for a PR without some kind of assurance that there will be an interaction
If Chris accepted PRs then we wouldn't be having this conversation! It is hit or miss. Very rarely he does take a PR and rewrite it his own way. More often (i.e. almost always) he ignores it, without a comment. Why on earth would anyone want to invest energy into this broken process? Furthermore, in the example I gave (async_initiate), fixing this documentation requires some cooperation from Chris. He needs to answer questions about how the thing is supposed to work. There could be nuances, which we would never know without his help. Looking at the web logs, Asio documentation pages are the most visited out of any other pages in the boost website. Asio is probably the most popular Boost library. This makes sense, because connecting to the Internet is very important. Boost has a flagship library, Asio, and the maintainer is unresponsive. This is a problem, and no one cares. Thanks
Hi dear community, It seems there’s some shared dissatisfaction with how Asio’s process currently works. From what I understand the key challenge is finding a way forward without “taking over” Chris’s role — and of course, if Chris is hard to reach, that makes collaboration trickier. One possible path could be to draft and review PRs collaboratively as a community. From Chris’s perspective, this could raise the quality bar enough to make merging easier/faster. For Boost developers, it provides a way to contribute and maintain some quality control without requiring a full takeover. And for users, it would mean faster improvements and iterations without the complexity of two Boost.Asio versions :) Naturally, this would still depend on a minimum of goodwill, time and communication from everyone involved. Best, Arno
On Fri, Aug 22, 2025 at 7:40 AM Arnaud Becheler <arnaud.becheler@gmail.com> wrote:
One possible path could be to draft and review PRs collaboratively as a community. From Chris’s perspective, this could raise the quality bar enough to make merging easier/faster. For Boost developers, it provides a way to contribute and maintain some quality control without requiring a full takeover. And for users, it would mean faster improvements and iterations without the complexity of two Boost.Asio versions :)
Great idea! I think you should email Chris and ask him how he feels about this. Let us know the response. Thanks
No dia 22 de ago. de 2025, às 16:43, Arnaud Becheler via Boost <boost@lists.boost.org> escreveu:
[…]
Naturally, this would still depend on a minimum of goodwill, time and communication from everyone involved.
It would also depend on the author manifesting himself, which seems to be the elephant in this room. Joaquín M López Muñoz
On 22 Aug 2025 17:13, Vinnie Falco wrote:
On Fri, Aug 22, 2025 at 4:14 AM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
The discussion showed that at least some issues and PRs are handled. Did you or anyone else try submitting a PR adding the missing documentation?
LOL Andrey! You're trolling me, right? Did you not read what I just said?
Who is going to bother doing the work for a PR without some kind of assurance that there will be an interaction
There never is any kind of assurance. Neither with Chris, nor with any other maintainer. You want something fixed, you file an issue or better yet, a PR. You're always at the maintainers' mercy regarding if and when it gets handled, but at least you do your part. OTOH, not reporting anything is a definite way to never get anything fixed.
On Fri, Aug 22, 2025 at 12:16 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
not reporting anything is a definite way to never get anything fixed.
You think I never reported anything? My proposal to fork asio is based on almost 10 years of experience reporting things. For example: https://github.com/chriskohlhoff/asio/issues?q=is%3Aissue%20state%3Aopen%20a... Thanks
On 19 Aug 2025 21:38, Peter Dimov via Boost wrote:
Christian Mazakas wrote:
Actually, am I reading this thread correctly in that Chris doesn't accept PRs, he just copy-paste-edits the code into no longer being a copyright infringement and then merges it himself into develop?
It's hard to tell from the outside, but I don't think Chris ever copy-pastes anything.
That's been his policy from day one; he only commits code himself. Before the move to Github this wasn't an issue because there was no way to submit a PR anyway.
You can disable issues on Github, but not PRs, or I'd expect him to have done so.
FWIW, from a brief look at commit history on GitHub, there are some commits that are authored by people other than Chris. I.e. at least in some cases Chris cherry-picks commits from PRs and preserves authorship. I think, if someone wants to accuse Chris in misattribution or plagiarism, he should present evidence of this. If there is no evidence then these allegations should be considered false.
On Mon, Aug 18, 2025 at 9:35 AM Artyom Beilis via Boost < boost@lists.boost.org> wrote:
...if something is needed it is a lightweight object oriented alternative to asio instead of template based one when for example stream socket handles both Unix domain socket and tcp without templates.
This is exactly NOT what this proposed fork is about. You are talking about innovating. I'm not opposed to innovation, and I am not offering it myself. If someone wants to write the hypothetical LATAST (Lightweight Alternative To Asio Sans Templates) then I would endorse a review of said library. I am not trying to write that library. Instead, I am talking about simply making a fork of asio which differs in these ways: 1. GitHub issues are responded to 2. A professional team is updating documentation 3. Some modernization where it makes sense to do so (std::error_code) 4. Closely tracks the upstream Asio repository Thanks
Vinnie Falco <vinnie.falco@gmail.com>:
On Mon, Aug 18, 2025 at 9:35 AM Artyom Beilis via Boost < boost@lists.boost.org> wrote:
...if something is needed it is a lightweight object oriented alternative to asio instead of template based one when for example stream socket handles both Unix domain socket and tcp without templates.
... This is exactly NOT what this proposed fork is about. ..
2. A professional team is updating documentation
Who is going to do it and pay for it? Artyom
Note what pdimov said earlier. This is a real concern when forking any repos: "That's going to be a maintenance nightmare. Not impossible, but would take quite a bit of effort from highly determined individuals and the job will get harder and harder with time as the two repos diverge." At the very beginning it's fine. But for every merged PR, and especially larger ones, the problem increases. Is the idea of the fork to accept pull requests that upstream ASIO ignored? Each time that adds to the repo difference.
On Fri, Aug 22, 2025 at 11:01 AM Sam Darwin via Boost <boost@lists.boost.org> wrote:
Is the idea of the fork to accept pull requests that upstream ASIO ignored?
A definite NO! The purpose of the fork is to track Asio as closely as possible (maybe even with no changes) and yet have responsive issues, pull requests, and improved documentation. For example, is Chris going to switch to Asciidoc? Is Chris going to use Mr. Docs? Who knows! Someone should ask him (and don't hold your breath for a reply). We don't even know if Chris is going to use the new system for reporting changes in the next release. Meaningful innovation is NOT a goal of this fork. If someone wants to write a competitor to Asio with redesigned APIs, I would be supportive of that, and this fork is not that. Thanks
On Mon, 18 Aug 2025, 22:56 Vinnie Falco via Boost, <boost@lists.boost.org> wrote:
On Mon, Aug 18, 2025 at 9:35 AM Artyom Beilis via Boost < boost@lists.boost.org> wrote:
...if something is needed it is a lightweight object oriented alternative to asio instead of template based one when for example stream socket handles both Unix domain socket and tcp without templates.
This is exactly NOT what this proposed fork is about. You are talking about innovating. I'm not opposed to innovation, and I am not offering it myself. If someone wants to write the hypothetical LATAST (Lightweight Alternative To Asio Sans Templates) then I would endorse a review of said library. I am not trying to write that library. Instead, I am talking about simply making a fork of asio which differs in these ways:
1. GitHub issues are responded to 2. A professional team is updating documentation 3. Some modernization where it makes sense to do so (std::error_code) 4. Closely tracks the upstream Asio repository
Have you tried submitting PRs for improvements to documentation and examples? That kind of change should be largely uncontroversial and more likely to be merged directly by Chris.
Hi, Just to note one of the arguments i've seen here is that low level networking and io control is extremely complex and so only very few people can meaningfully contribute. This is an enormous red flag for anyone looking at using Boost ASIO from a supply chain analysis perspective. It's not a massively big practice at the moment but is growing. Fundamentally being in a situation where only one person has the knowledge required to safely make changes to a open source package is not a good place to be. Best wishes George
This has been the same impression I got from reading this thread: "all the good books have already been written". I agree that this possibly will have a negative effect on anyone attempting something new. Even any potential returns in maintaining a fork itself are greatly diminished under this premise. Claudio.
Am Fri, 15 Aug 2025 11:14:58 -0700 schrieb Vinnie Falco via Boost <boost@lists.boost.org>:
I would like to measure the interest in a fork of Asio, proposed as a Boost library for review.
As a long time user of boost and asio (since boost 1.33), i would like to give some insight on my side: 1) It is used by me in personal and professional projects. Its used because it offers tcp/http/serial and unix sockets. 2) Would always use what boost offers as it is pretty well supported (most times) and also offered by basicly all linux distris. 3) I think that the API of asio is relativly well known. It is complex for users too. Especially when i need to explain it to new programmers in the company which dont have so much expierence wich asio and c++. As we all know: C++ is expert friendly. So is in my opinion also asio. Bye Georg
participants (23)
-
Andrey Semashev -
Andrzej Krzemienski -
Arnaud Becheler -
Artyom Beilis -
Christian Mazakas -
Claudio DeSouza -
Daniela Engert -
Georg Gast -
george.sykes＠connectorsubsea.com -
Ion Gaztañaga -
Ivan Matek -
Janko Dedic -
Joaquín M López Muñoz -
Jonathan Wakely -
Klemens Morgenstern -
Klemens Morgenstern -
Peter Dimov -
René Ferdinand Rivera Morell -
Sam Darwin -
Seth -
victor.whiskey.yankee＠gmail.com -
Vinnie Falco -
Vinícius dos Santos Oliveira