For some people, I surmise, simply the set of decision making I've implied (and will shortly sketch), is fun all by it self. We start, for example, from a frustration with a product we use. We view it's source, review it's history, and find some rationale for the unsatisfactory design. Considering this, we might know of a new technique that addresses a concern raised, that way addressing the accepted reasons that were blocking our feature. (With large projects most obvious features have reached the cutting room floor one or more times, it's wise to tread carefully, and it makes for a better story.) Armed with this rare knowledge then, of advanced means to reasonable ends, we may come in swinging, especially into a packed arena, spoiler for a chance to land a few choice points in the meta while we try to land a patch that puts things right with the world. I can see where that gets fun.

For me, I think I might enjoy the complexity for it's own sake: It's a rush when I can grasp a problem that feels elusive.

But let's look at it from a risk surface perspective, considering first complexity first on a scale of "worthy-fun to unhealthy-timesuck" looks manageable for starting by considering the most complicated parts of a thing first:

1. I might get confused and reach no conclusion saving epic amounts of my own time,

2. I might find things simpler than expected (a treat, to be sure), or

3. I might see how some complexity could be accessible in a potentially simpler manner (whereupon we'll have to hope this is fun as we'll undoubtedly explore further).

In contrast, if we focus first on the parts of our conceptual solution we suspect are easiest to accomplish, let's look at what we can win:

1. if we are right, we may be able to implement a large amount of our application without inventing anything. boring, but I see where you would be going with this line of reasoning, to be sure.

2. if we are wrong, we may be having feelings, e.g. having failed to make technology we had been thinking of as simple "just work" for our purpose, it's not uncommon to be sad and angry. Not too fun.

Admittedly that first possibility along the get-it-mostly-working-first lines didn't look too bad. But I think it's worth more closely introspecting our motives. In particular there's a real recruitment factor in capturing people's imagination with a solution that does a meaningful but incomplete set of what a number of people are hoping may be possible. Even when we don't know or suspect a rapid audience from prospective contributers, we might be more likely to attract the focus of an expert with a "scaffolding" grade solution. Honestly, and again with the strictest of focuses on only my personal and not any of my professional technology pursuits, that all basically bites.

The Operating System vision provided by GNU is of a coherent system of tools which work well and work well together, that's a clear demarcation and should be taken starkly as a way-point when we trouble to imagine contributing important new functionality to the libre/free-software ecosystem, as admittedly not all our things do.

Tesler's Law drives us to consider our designs in terms of the appropriate complexity to expose to users, as well perhaps as how to compose for other maintainer and the curious, stating:

Every application has an inherent amount of irreducible complexity. The only question is: Who will have to deal with it — the user, the application developer, or the platform developer? The Law of Conservation of Complexity

Now we're down to one question: whom shall "deal with it". Fun, for sure.

It's not what you think. Well. It could be what you think.

Sometimes we have a pretty clear instinct about what will inevitability drive complexity into our solution. For example, let's say we have in mind a transient based interface for video workflow automation. With this we might anticipate some difficulty avoiding e.g. having some approach expressing the different tool/packages/configurations and media formats "in the wild".

This nicely illustrates Tesler's Law: we have some liberty to chose the freedoms we will offer the user, to close-off difficult to support usages in the name of maintainability, and to provide User/ Application Programming/Customize Interfaces, and thus pass the buck along, hopefully, with remarks and examples if no other "value-add".

If you are going to drop in, unannounced, unasked, with complexity someone may trouble themselves to learn, it is more than reasonable to spend some time struggling with and socializing your notions of- let's call it flexibility, as "simplification" seems presumptuous.

This could mean proposing a new format or semantic or an "intrusive" patch to existing one, or who knows. The goal will be to make a long term contract with your users about what they will need to remember about your program to install, configure, and (re)learn to use it. And too with any who may cooperate with (or subsume!) your own development, and must rationalize your decisions.

Returning to the "goal posts" as outlined for the GNU Operating System, we can see that our mandate is to think comprehensively about our program's role among others. Seasoning our "inevitable" complexities as may compassionately conserve stresses among our users (much less respectfully distributing the burden of inventing, learning, and adopting new practice among application, platform, and ecosystem collaborators) will be a meaningful chore.