For months now, Ruby Central has caused great disruptions and made many missteps in how they’ve communicated to a worldwide community of Ruby developers.

In the last several weeks I’ve seen some incremental improvements in their attempts at repair. Some questions are being answered, some changes are being made to add in new and constructive voices in key places in their governance structures. Much of it feels like too little, too late, but it’s still progress and something is better than nothing.

...

There’s still an elephant in the room though. Until Ruby Central shows meaningful accountability for their own historical abuses of power (even if they were with “good intentions”), there will never be a way to restore trust.

One board member in particular has played a key role in many of the controversial and damaging choices that Ruby Central has made, and that is Ufuk Kayserilioglu.

...

Ufuk has openly acknowledged that he is the individual who specifically extended the invite to DHH to offer a keynote slot for RailsConf 2025, and in fact, had attempted and did not end up securing a keynote talk for DHH in RailsConf 2024 as well, with Ruby Central’s board approval.

This choice is fundamentally linked to the loss of funding that Ruby Central has experienced, regardless of anyone’s individual opinion of DHH. This is the domino that was tipped that spiraled into putting rubygems.org, RubyGems, and Bundler at risk, and an unambiguous driving force behind all that has happened in recent months.

But even without taking RubyGems into account, and regardless of whether or not DHH has “earned on merit or historical significance alone” a guaranteed keynote slot at RailsConf, the way that Ruby Central carried out inviting him, announcing the invitation, and dealing with the community response to that invitation, were fundamentally flawed.

Ufuk is at the center of this, and for that reason, is the most directly responsible person for all of the fallout that has come from that point forward.

For that reason, I am asking him to act with integrity and step down from any further involvement with Ruby Central, immediately.

And failing that, I am calling on Ruby Central’s board to carry out a vote of no confidence imploring him to resign for the same reasons.

I have submitted a statement to this effect to Ruby Central, which I have included in its entirety below. It consists of a series of simple yes or no questions.

In your Nov 7 update, you responded to my question in which I had asked if the board would consider asking Ufuk to resign due to his perceived conflict of interest with a message that started with "We appreciate the opportunity to address this directly."

In your reply, you did not address the topic of resignation at all, but instead reiterated that "sponsors do not have governance or program authority at Ruby Central. Conference programming decisions are made independently by the co-chairs and program teams"

So I will try to ask the question again, in parts, each of which can be answered with a simple yes or no:

1. Is it apparent to Ruby Central's board that when a keynote speaker is a board member of a 200 billion dollar company, and a program chair who is employed by the same company arranges a by-invite keynote slot, that there is a potential for perceived conflict of interest?
   

2. Is it apparent to Ruby Central's board that when a program chair is also a board member of Ruby Central itself, that there are inherent challenges in making indepedent programming decisions?"
   

3. Is it apparent that when a sponsor for a non-profit organization provides a sufficiently critical amount of funding and in-kind services so as to make the organization operationally dependent on their continued funding and support, that there are power dynamics involved that necessitate going "above and beyond" in anything related to perceived or real conflict of interest?
   

4. Is it apparent that when a program co-chair is also a Ruby Central board member and is also an employee of the same company that the invited keynote speaker is a board member at, and that the keynote has specifically been identified as not up for consideration by the other program committee members, that there is a reasonable risk of perceived conflict of interest?
   

5. Is it apparent that when the same keynote speaker's talk is announced via Ruby Central's official account with comments turned off on Bluesky, this creates the appearance of an organization who is aware of and actively trying to minimize negative publicity regarding their programming decision?
   

6. Is it apparent that when a listening session is scheduled with a promise to release a recording afterward regarding this decision, and neither that recording, nor a transcript, nor even a substantial summary of the key topics discussed in that session were published, that this furthers a public perception of evasion and deflection regarding the decision made by Ruby Central?
   

7. Is it apparent that when sponsors are inadequately informed of these decisions in advance and as a result decide to withdraw funding (or withdraw continued support), that significant financial harm has been done to Ruby Central's funding position, creating an increased dependence on the same sponsor that all relevant parties in this decision are affiliated with?
   

8. Is it apparent given all of the above, that at a minimum, Ruby Central's board should consider a vote of no confidence in the board member and program co-chair who made these choices, so as to set the organization on the path where there can be meaningful reform?
   

SOURCE:
https://github.com/community-research-on-ruby-governance/questions-for-ruby-central/commit/26365af9269d4851e471e3c54385d1c0fe44e170

If you find yourself saying “Yes” to several of these, please consider joining me by sending an official reply to Ruby Central recommending that they ask Ufuk to resign.

And if you want to go on public record, you’re also welcome to submit your reply to this questions repository.

...

For what it’s worth, at this point, I truly do believe that Ufuk believes that he was acting in the Ruby community’s best interest, and that he also believes he was acting independently. 

This is not a conspiracy theory. I don’t think that Shopify or DHH directed Ufuk’s actions or otherwise threatened any form of negative consequences for not delivering on this benefit to DHH.

However, I believe that structurally, the nature of the relationships that exist here are exactly the sort that explicit and strong conflict of interest policies are meant to address. The vast majority of influence of power is voluntary, implicit, and never explicitly verbalized. 

The more power there is at work, the more this is true. The more critical the scope of someone’s responsibility, the more responsible they are for being aware of how power works in practice, not just in the letter of the law and the letter of corporate bylaw.

...

Those who are indifferent to power structures at best, and passive beneficiaries of them at worst, do not belong in stewardship positions. Especially when they don’t seem to learn or grow when called out on their own (potentially unintended) misconduct.

My sincere hope is that Ufuk takes this as a learning experience and voluntarily steps down from Ruby Central. In doing so, he would be carving out space for new stewards to step up and learn from the mistakes that were made so that the Ruby community as a whole can move forward.

This will be my final statement regarding Ruby Central for the remainder of 2025.

In the end, this comes down to “What do you stand for?”, and I implore Ruby Central, Ufuk, and every developer in the Ruby world to consider that and act in accordance with their own values.

I have done my best to stand up for mine.

Now I need a rest, because this has been exhausting.

Here’s hoping for the best as the board reshapes itself heading into the new year.

Half right is the most dangerous place to be when it comes to anything involving technology.

I think about this every time I see something cobbled together in a weekend to which the author says “This was 100% vibe coded, I could have never done this so quickly on my own!”

With rare exception, I look at the end result and think “I definitely could have done that in a weekend too, coded the old fashioned way. And not only that, I’d understand how every part of what I built worked, and what tradeoffs I made while working on it to get it done sooner than later”

But that too, is only half right. I could say that confidently about anything I’ve already done before, using the tools I’m familiar with. I could say that if I controlled the scope, and the tolerance levels around tech debt.

Throw in even the smallest complicating factor, and I’d need to spike to get a real answer. It’s possible that my entire plans could be thrown out the window by some random system dependency that’s very difficult to install, even if that’s buried deep down six levels away from the problem I’m actually trying to solve.

Vibe coding might route around that with a random flag to disable some newer security checks that otherwise would prevent the whole program from running. I might do that too, if I knew the risks involved and made an informed choice.

The vibe coder who copy pasted the cryptic error back into their LLM without even reading it? They might never know, or care.

What did GenAI prove about the software development world as it sits right now? That it’s an enormous mess and that a large percentage of the population would rather sweep that under the rug rather than fix the issues at the roots.

That’s the danger of being half right.

It’s time to stop pretending that “normal life” exists in a world that’s burning.

The amount of focus and energy required by any sort of skilled labor is higher than what most folks have capacity for at the moment. So many are tired, sick, scared, enraged, endebted, and <insert other bad things here>.

Money can be used as a salve by those who have it and those who can still borrow it, but the cost of convenience, comfort, and safety is trending to infinity. Most everyone else is watching every dollar they make burn alongside the world, simply to get through the day.

Failure to adapt is where most suffering comes from. But it’s not clear that any of us know how to adapt to the world we’re living in.

So it seems worthwhile to get back to basics.

To do that I’ve been looking at Maslow’s Hierarchy of Needs, which states the semi-obvious… figuring out how to pay for and acquire the food on your plate always comes before building capacity to solve the more complex problems of life.

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

This statement from the author of Gödel, Escher, Bach is one of those things that has rattled around in my head for decades because of how true it is. And yet, it is one of those observations that feels like there’s nothing that can be done about it… and so it’s a bit like saying “I just lost the game” every time you think of The Game.

At least that’s what I thought, until I saw a Mastodon post from Robert Roskam that opened up a new line of thinking for me. In particular, he suggests that “The solution isn't better estimation; it's shorter feedback loops.”

I’ve been mulling that over since I saw the post the other day.

My gut reaction is to say “Aha! Feedback loops are indeed at the root of all this… but is shorter always the answer?”

That’s my systems thinking brain kicking in… feedback loops are indeed often too slow in most human activities. But on the other hand, oscillations and vicious cycles can be caused by feedback loops that are either too short or too frequent… so there’s a balance to be found there that is probably quite context dependent.

And so perhaps it’s worth deliberately blurring things a bit to leave room for more reflection, while still serving as a navigational aid of sorts, with this rephrasing:

“The solution isn't better estimation; it's better feedback.”

This leaves it up to the individual to define more precisely what better feedback means.

But it still calls out that the cause of delays (particularly unanticipated delays (and particularly unanticipated delays despite a lot of analysis being put in to determine the likely sources of delays (and particularly when that happens even when you’re aware of the phenomena ))) — is probably in whole or in part because the right information didn’t reach the right place at the right time with the right level of detail to allow for swift course corrections.

This is a new thought for me! Or at least a new angle on a pattern that shows up in a thousand different forms.

So I’m thankful to Robert for stirring it up. :)

This is a waypoint entry, which includes a progress report along with some personal notes on what I’ve been up to in my work on building Skills to Practice.

Work on Bug Hunt was consistent from its first early access release on March 14 until v0.6.0 shipped on May 17.

Then life got complicated for me as family obligations took center stage for the last two months. I was in a place where I had to assist with some important changes for those nearest and dearest to me, while also shoring up my own foundation as well.

There’s still a good amount of grinding left to do on all of that, but little by little I find myself recovering. Regaining excitement about this project because I never ran out of steam on it by any means… just had to give my full attention elsewhere for a while.

The tricky thing for me at the moment is figuring out how much to focus my energy on Bug Hunt in particular vs. laying the groundwork for Skills to Practice as a whole. But that’s more of a question to sort out over the next few months, rather than the next few weeks.

Over the next few weeks, my immediate next steps are obvious:

• Ship Bug Hunt v0.7.0 as soon as possible.

• Hit the halfway-done point for Bug Hunt by August 15.
  (only six more exercises shipped would get me there)

• Finish all but the “challenge exercises” and get those through beta testing with early access readers by the end of September.
  (this would bring the guide up to 42 exercises in total)  

• Publish frequent waypoint entries on this website to keep myself motivated and make it easy for others to see what I’ve been up to since they last checked in.

The rest can be sorted out as I go.

Onward!