licensing

An important conversation is around what is the value of this tracing tool and how much time we should spend on developing it let alone documenting it.

To me, my immediate intuition is that like PANIC, this tracing tool is extremely valuable and useful outside of any GUN related context. So again like PANIC (and RAD, and SEA, and...) my belief is the tool should be modular and decoupled from GUN but designed with the intent of seamlessly integrating/plugging in with GUN.

I think what you've done here, is genius, clever, and simple - yet takes brilliance to think of. So it has all the checkmarks in my head of things I think of as being good tools. But followed by some disclaimers:

• (1) PANIC is that way also, but sadly, you see very few people use PANIC or even talk about it, despite it being a potentially more powerful and widely-applicable technology than GUN itself. Why is that...

thats because these are tools for tool makers, people who write databases or operating systems or libraries. Which is partly why they are so important and powerful. But there power is equal to their scale... for every 1 database developer there are 10K app developers who use the database, for every 1 app developer there are 10M+ users, likewise for operating systems. The chance of a user needing this is like 0.01%, the amount that an app developer should use this tool is probably like 10% but the chance of app developers actually using it is like 0.1%, then finally, back in the category it actually belongs to... the number of database/OS developers that should use it is like 100%, but the chance of those that actually will? Is probably like 10% at best 1% in reality.

so, the furthering of the tool (let alone its documentation) should primarily be a function of how well it serves/improves our productivity as we are that 1% of database/etc. devs that in actual reality use it. With one special twist...

• (2) Enterprise Utility. I actually believe that these types of tools, the tracing, PANIC, etc. have the most ethical alignment with being Open Source but also selling it for profit. As yes, the majority of Operating Systems and low level infrastructure (cloud systems, etc.) are run by thee most profitable enterprises in the world (Apple, Amazon, Microsoft, etc.), now the chances of us being able to sell to them may be low cause we aren't bizdev/sales people that know how to do all the buddybuddy political smoozing, but it is fair game: It is valuable, rare, unique, and means we can put a steep price on the "commercial" version of it.

I don't think GUN should ever have a "commercial" version, as what I see GUN doing is something everybody needs (including those end users, even if they don't know what "engine" they're using underneath). A better car engine for everybody is a better world for everyone.

However, how the mechanics that invent the cars test/probe/inspect/diagnose/debug building the car? Does that really need to be Open Source? Well, my philosophy is why not let it be Open Source, so we became the industry standard for all (analogy) car manufactures out there, but I have no moral/ethical qualm (problem) with requiring a commercial license to actually "use" it. This is one "licensing" area I could see somebody going with Open Core (ahem, crippleware) or other, but I still think it is actually better and simpler to just do it as "The OSS license only extends to organizations with less than 10 employees or contractors. Above that, you must purchase the commercial version for $insanely_huge_amout annually which comes with included training/support/maintenance/consulting, if you are a non-profit or similar or have less than a 100 employees or contractors, we offer a discount."