Thanks Martin, that's really empowering! ❤️ On Fri, 6 Mar 2026 at 03:06, Martin Blais <[email protected]> wrote:
> On Wed, Mar 4, 2026 at 7:17 PM 'Simon Guest' via Beancount < > [email protected]> wrote: > >> Well, if you think it won't work then perhaps it's not a good idea! >> >> Are you thinking there is insufficient interest in the community for >> refining such ideas collaboratively? If that really is the case then I fear >> we are doomed to suffer from fragmentation, as different people go off with >> their own ideas in different directions, and we lose a coherent vision for >> what it means to be a Beancount implementation. >> >> Or did you see a different problem? >> > > I just think ideas that work always come bottom up. It's so rare that > someone says "let's form a group to achieve X" and then "X" gets achieved. > The working dynamic in open source is one or a few individuals axed to get > something they really really personally want and then take enough pride in > it to make it available to others. That's why nearly all the open source > project have 1 or few principal creators. > > Look I don't want to discourage you, I'm just saying, if you really want > something done, drive it yourself without trying too hard to get consensus > from other people. To recycle the trope: just do it. Do things the way you > dream of, and if it's great you'll then have some takers to discuss with. > I've shared all my ideas on what I think needs to be done on Beancount in > these documents, feel free to recycle or ignore them or take them to a > brand new place your own. > > > > On Thu, 5 Mar 2026, 2:10 am Martin Blais, <[email protected]> wrote: >> >>> On Tue, Mar 3, 2026 at 10:58 PM 'Simon Guest' via Beancount < >>> [email protected]> wrote: >>> >>>> So, towards caring for those little details in a collaborative way, how >>>> do you feel about creating a new GitHub repo, say, beancount-vnext-rfc in >>>> the beancount organization? The intention being that developers wishing to >>>> gain some clarity on what to implement can create an issue, and interested >>>> parties can comment. That way we will collect the discussion in a central >>>> place which is searchable and contains the full history of comments on each >>>> topic. GitHub issues are quite good for this, as anyone can subscribe to >>>> an issue or to the whole repo. >>>> >>> >>> I don't mind creating beancount-rfc but I think it won't work. >>> >>> >>> We have seen two instances of this being required already, regarding >>>> the new approach to inventory being taken by TurboBean, and the false-start >>>> on plugins I was investigating. It is clear that this mailing list is not >>>> going to suffice, and trying to discuss all that here is only going to >>>> annoy people who aren't interested in alternative implementations (which I >>>> concede may be most people right now). >>>> >>>> If you created the repo and gave me write access, I could set up an RFC >>>> template to try to get things going in the right direction. >>>> >>> >>> Sure, I can do this over the weekend >>> >>> >>> >>> On Wed, 4 Mar 2026 at 15:18, Martin Blais <[email protected]> wrote: >>>> >>>>> So long a thread. >>>>> I appreciate the flowers but let's not forget the original idea is a >>>>> John Wiegley creation, I merely copied and then iterated and recreated a >>>>> few times. Simon Michael also accumulated a following with his Haskell >>>>> work. Credit where credit is due. >>>>> >>>>> Re. BDFL indeed I don't have time. I'm giving all my cycles to someone >>>>> else at the moment. (Thankfully doing lots of agentic stuff so it's not >>>>> like I have FOMO.) >>>>> >>>>> I think the idea of having unified tests is a great one but it's >>>>> unlikely to happen, people enjoy the 0 to 1 feeling mostly and this won't >>>>> change with agents. Maybe you can extract all the tests from my source >>>>> code >>>>> and find a way to them across equivalent systems (see how I assert some >>>>> things in the beancount syntax itself, you don't necessarily need code, >>>>> you >>>>> can create a syntax). >>>>> >>>>> The main challenge to new implementors is going to be completeness. >>>>> With the AIs zero-to-0.8 is almost instant; your enemy will be 0.8 to >>>>> 1.0. >>>>> Lots of little details to care for. >>>>> >>>>> >>>>> >>>>> >>>>> On Fri, Feb 27, 2026 at 9:51 PM Justus Pendleton <[email protected]> >>>>> wrote: >>>>> >>>>>> I think it is a great idea to encourage experimentation and evolution >>>>>> of the fileformat/featureset. >>>>>> >>>>>> My feeling is that Martin probably doesn't have the bandwidth to play >>>>>> any significant BDFL-type role commenting on various proposals or >>>>>> shepherding towards consensus. So the beancount family is probably better >>>>>> served with something a bit more free-form. I could see value in a >>>>>> centralised repository where alt-beancounts could post "hey, here's what >>>>>> I'm trying out", a bit like we've seen with the various flavours of >>>>>> markdown over the years which also don't have a BDFL but have evolved in >>>>>> a >>>>>> bit more chaotic fashion. >>>>>> >>>>>> I think the biggest value-add at the moment would simply be some kind >>>>>> of unique number for each change from vanilla-beancount so people could >>>>>> talk about "change #12 in limabean is easier to use but less powerful >>>>>> than >>>>>> the similar change #26 in prolog-bean" and provide a focus for >>>>>> discussions >>>>>> like RFCs do. I can't imagine trying to enforce too much structure on >>>>>> either the document or the process would be very useful, simply because I >>>>>> imagine most people writing alt-beancounts aren't terribly invested in >>>>>> writing long documents in prescribed formats for what is still largely a >>>>>> personal project. >>>>>> >>>>>> But if you have more lightweight examples from smaller projects (i.e. >>>>>> not rust or python which understandably have rigorous processes) it might >>>>>> help generate more ideas. >>>>>> >>>>>> On Thursday, February 26, 2026 at 11:25:49 AM UTC+10:30 Simon Guest >>>>>> wrote: >>>>>> >>>>>>> The Beancount developer landscape seems to be thriving at the moment >>>>>>> with several recent announcements about new implementations. This is >>>>>>> certainly exciting, and it's great to see such creativity. >>>>>>> >>>>>>> Martin has made a huge contribution to the plain text accounting >>>>>>> community, both with the very well designed original Beancount system >>>>>>> which >>>>>>> we all love, and also the extensive documentation and test suite. Thank >>>>>>> you indeed! These were certainly enablers for my own limabean >>>>>>> <https://github.com/tesujimath/limabean>. >>>>>>> >>>>>>> And so now times are changing, and Beancount is in some ways being >>>>>>> liberated from its Python origins. We are seeing work in Rust, Zig, >>>>>>> Clojure, and who knows what to come. Exciting times indeed! But how >>>>>>> will >>>>>>> we avoid fragmentation? >>>>>>> >>>>>>> It is clear that in future we will have multiple implementations of >>>>>>> Beancount-like systems. That is not what I am concerned about. My >>>>>>> concerns are: >>>>>>> >>>>>>> 1. Preserving a common file format >>>>>>> >>>>>>> 2. Preserving common core behaviour >>>>>>> >>>>>>> I expect and celebrate a varied approach to user interface >>>>>>> (Beancount Query Language, Fava, or Fava-like GUI, Clojure, whatever >>>>>>> else). This is a fruitful area for exploration. So too, the plugin >>>>>>> ecosystem will surely diverge. I agree with Moritz, the author of >>>>>>> TurboBean <https://github.com/themoritz/turbobean> (cool project!) >>>>>>> that you wouldn't want to embed a Python interpreter just for plugins if >>>>>>> you don't already need it. And with limabean I am exploring the idea of >>>>>>> not needing plugins at all. >>>>>>> >>>>>>> It should be easy for users to try out different implementations, >>>>>>> which requires (1) and (2) above, and perhaps more. >>>>>>> >>>>>>> The vNext document >>>>>>> <https://beancount.github.io/docs/beancount_v3.html> has some >>>>>>> interesting ideas, which explains TurboBean diverging with a new >>>>>>> approach >>>>>>> to inventory. Is this the future? I would like to know, as I would >>>>>>> then >>>>>>> have to follow along with limabean! >>>>>>> >>>>>>> What I would really like to see is some kind of RFC process, like >>>>>>> which is used for evolution of the Rust language and ecosystem. I hope >>>>>>> that Martin would like to be the BDFL for some kind of RFC-like process >>>>>>> which unifies all these parallel developments, in terms of defining core >>>>>>> behaviour, *especially where this differs from OG Beancount* (in >>>>>>> fact, probably only where it differs). >>>>>>> >>>>>>> In summary, I think we should embrace and celebrate the current >>>>>>> divergence of implementation work in the Beancount ecosystem, but take >>>>>>> some >>>>>>> steps to mitigate the otherwise inevitable fragmentation. >>>>>>> >>>>>>> All comments welcome! >>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Beancount" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To view this discussion visit >>>>>> https://groups.google.com/d/msgid/beancount/3a441c4c-5e54-4ef0-bc6d-39f7bb683923n%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/beancount/3a441c4c-5e54-4ef0-bc6d-39f7bb683923n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Beancount" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/beancount/CAK21%2BhPGzU%2BFjuKh_oxXsQ7eQMcigTUVygPv%3DQPQ8Do%3DqO-iEg%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/beancount/CAK21%2BhPGzU%2BFjuKh_oxXsQ7eQMcigTUVygPv%3DQPQ8Do%3DqO-iEg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Beancount" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion visit >>>> https://groups.google.com/d/msgid/beancount/CAFhGSbt4fY0W6dX-Zd9W2%2B3PdGnSXPQZsBzGUsiQwspGQLnPPw%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/beancount/CAFhGSbt4fY0W6dX-Zd9W2%2B3PdGnSXPQZsBzGUsiQwspGQLnPPw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Beancount" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/beancount/CAK21%2BhN33-5u0hb8d7%3DVOo-LXczMHjV59GzDb03S6gajze2CWw%40mail.gmail.com >>> <https://groups.google.com/d/msgid/beancount/CAK21%2BhN33-5u0hb8d7%3DVOo-LXczMHjV59GzDb03S6gajze2CWw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Beancount" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/d/msgid/beancount/CAFhGSbveq8AWX-SA%2BZCPU1Eg27YNoRaQb2Tknj_%3D2BRtaUeZxQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/beancount/CAFhGSbveq8AWX-SA%2BZCPU1Eg27YNoRaQb2Tknj_%3D2BRtaUeZxQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "Beancount" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/beancount/CAK21%2BhPGBL-b1J0OE9_oCOk3DWGXH_A0BLK_gORanfoV_fEe3A%40mail.gmail.com > <https://groups.google.com/d/msgid/beancount/CAK21%2BhPGBL-b1J0OE9_oCOk3DWGXH_A0BLK_gORanfoV_fEe3A%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/beancount/CAFhGSbuR_RO%3Dxy-CDffLm1p_09WmBrU%3DpjJpNr94yzZ4ytFSJg%40mail.gmail.com.
