Exactly.

Discussions are great and all but discussions also involve listening to both sides. At some point, things seemed to go one sided. Developer burnout is a *huge* problem in open source so Fred’s concern about maintainability vs. extensibility is valid. Maybe that concern wasn’t quite coming through over email. I can personally say, OS developers tend to start getting into a situation were they work on things not because they are interested anymore but because they feel like they *have* to support the needs of others … for free. That’s where things get toxic and it’s sometimes hard to find a balance between the two.

I’m not trying to figure blame, etc, I’m trying to see what we can all learn from this unfortunate outcome.

Instead of consistently asking for Fred to integrate and increase his workload, the better course of action might have been to make a companion library that utilizes cyclone and begins adding functionality. Maybe start with abstractions and go from there? Putting up code and workable ideas always influences things more than "here’s a huge bug/feature list for one person to implement.” Oftentimes, if the work is good and the developer can see things are coming together nicely, talk begins about a possible integration with the base code base and direct collaboration. This has been the case in the OpenFramework community where a few addon libraries have been vetted and proven outside of the core code, then integrated later on.

That being said, the huge compatibility list a *great* resource and basis for organizing work for a number of people. Sometimes, QA is great help in defining what makes sense beyond the developer perspective. Throw that up on a wiki with checkboxes and bring your students in on a “make an external/abstraction party”. :)

Fred did a large amount of work in bring cyclone forward, build-wise and bug wise. Why wouldn’t you start with his work? Seems like a step backwards after all of this...