D Is Not A Corporate Language

Allow me to explain.

Mike Parker of The D Foundation Leadership recently posted on the DLang Forum (here) about the IVY Leadership Training that the Foundation leaders completed over the past few months and I'll admit that my initial reaction didn't amount to much more than a mental shrug. I've seen so many of these programs come and go over my career, with so little impact, that I mostly consider them to be an expensive waste of time. However, there were a few responses to the post that I found interesting. Specifically, two posts by a user named "monkyyy". (Internet handles are fun to type, don't ask how many times I had to reread that to get it right.)

The first post is mostly just a link to a blog post they wrote (here) in which they discuss their views on the future of D. And while there is much in that blog post that I disagree with, and I may write a future post about, there is one segment that practically leapt off the screen, and that I completely and wholeheartedly agree with:

You are simply not Go where you can have strict idiomatic language and the std is funded with google money. Or C++ where Microsoft with Enterprize-Grade mediocrity implements whatever API you put out. -Monkyyy

This is correct, D does not have a single corporate benefactor that provides all of the necessary financial and engineering support that is typically required to build out a comprehensive standard library similar to Java (Oracle), .NET (Microsoft), or even the more limited standard libraries of C++ (Microsoft/Apple/etc.) and Go (Google). It does have a few corporate users who contribute opportunistically but there is no steady source of resources for the boring work.

In my opinion, this has been a net benefit to D as it allowed the language to mature and grow in the direction that was most beneficial to the language itself without interference from the corporate need to show a profit on its investments. D has made several pivotal design choices over the years that have made the language incredibly useful and allowed it to earn broader industry adoption as time goes on.

The Benefits of "Going Corporate"

However, along the way D has turned down a few blind alleys that were allowed to grow out of control. And this brings us to the first benefit of making D more "corporate".

One of the major benefits of corporations is that at some point, they must ship something. And that something had better be useful to a maximum number of people because they need to bring in as much money as possible to continue to survive. This need forces corporates to make the painful decision to cut features that are either too niche to be broadly useful or are soaking up limited resources that could be better spent on other projects. It is always better to cut and pivot sooner rather than later. That said, "cutting" is often a euphemism for pausing a project until more resources become available or a more efficient solution is found, and frequently, a more efficient solution is found that ends up getting the project officially cut in favor of the new solution.

Many in the D community find this abhorrent to the point of outright blasphemy. The most frequent counter-argument I hear to something getting cut is "Without this feature the language is completely useless to [myself/my company] and [I/we] will be forced to stop using D." Setting aside the obvious hyperbole, the vast majority of the time what the author means is "I'll have to work harder to accomplish the same task and I don't want to, so I'll just move to [insert language here] instead."

This brings us to another advantage of corporations. Corporations are always balancing the need to ship something that works with the user demand to ship something that does everything they need. Without this balancing, it is far too easy to fall into the tarpit of Ideology Driven Development, which is a subject broad enough that it requires a separate article so I'll leave further discussion until then.

This brings me to the final significant benefit of going corporate. The limitations imposed on corporations require leadership to articulate a clear vision and path forward for D. Then once that vision has been articulated and the path laid out it becomes the responsibility of leadership to make sure that the whole community understands that this is the direction we are going. However, there is one critical difference, there is no requirement that the entire community agrees with said direction. This is not to say that the vision should be developed without community involvement, indeed there should be as much involvement as possible, but it needs to be stated and accepted up front that not everyone is going to be happy with that direction, and that is OK.

An example of how this might look in practice is that Pull Requests that directly work toward the desired direction receive higher priority than PRs that may add useful but otherwise unrelated work. There is no need to prevent people from contributing, but they need to understand that their work is a lower priority, and they need to know that before they even start.

Going Corporate

My view of the D Language Foundations' introduction of IVY is that IVY is nothing but a tool, no different than EMACS, and just as it's not EMACS' fault you wrote a bug, the potential utility of IVY comes not from its mere rote application, but how intelligently it is applied to achieve the goals of the Maintainers and the Community. If IVY can help the DLF and the Maintainers pull us out of the tarpits of Ideological Warfare, improve the clarity of vision or direction, or even encourage the Maintainers to start cutting sooner, then IVY will be a benefit to D and the community. IVY is just a tool, how it's applied is the most relevant factor in measuring its future success.

Furthermore, the very introduction of IVY appears to have caused the stir it did simply because IVY itself is "corporate" and anything perceived as corporate is going to cause significant heartburn among certain segments of the D community, particularly the more Ideologically driven segments. They are right to be worried. Becoming more corporate means that there is less room for Ideological Purity, it's why they left those prior languages and came to D in the first place. We must accept that there will be a noticeable number of folks who are unhappy with any new direction and may choose to leave. In my opinion, that is an acceptable loss, because while these folks can be prodigious contributors, they are also very willing to obstruct anything that does not support their Ideology, even to the detriment of the broader community.

When Mike Parker gave his talk on the history of D at DConf 2022, he wisely ended the talk at the "D is a Town" phase of community development. One of the major differences between a Town and a City is that the Town does not provide all the services the average human consumes, your basic needs are met, but you are likely to need to travel to another (bigger) Town or even the City to gain access to the most advanced/complicated/expensive services you might utilize.

D is not that City. Yet. But it absolutely can be. To make that leap to a City D must focus on direction over ideology, consistency over appeasement, and expanding services over expanding the language. Successfully executing on that is going to require that D begin to take on corporate practices, of which IVY is only one, and arguably not even the most important, but if it moves us towards becoming the City we need to be, then I am all for it. Finally, adopting a more corporate tone will make it easier for corporations to adopt D, and that adoption will be critical to expanding the services that D provides.

In a future post I will talk about what expanding those services may look like but for now, let's ship some code!