I just wanted to let folks know this is not about eZuce taking Avaya's place. That wouldn't be very useful. With the copyright assignment agreement out of the way, everyone one is on the same playing field. eZuce contributes because we found a way to profit in a community driven, open source software business. If you are doing the same or planning to do the same then you're just like eZuce. SIPfoundry sipXecs project needs you to have *more* control not less. eZuce recognizes that you need that control to build a successful business from sipXecs and therefore continue to stick around.
As the first small step in this pledge, much of the infrastructure to run SIPfoundry will be created under accounts not tied to eZuce in as much as that is possible. I will share these accounts with various members of the community so we never have to go through this infrastructure transfer again. Martin may pull together a roadmap based on what he sees eZuce contributing, but it's not meant to reflect what get's in. I would recommend that we keep the same rules that have always applied as far as open communications about your intentions before you contribute a substantial amount of code. That brings me to source control and martin pointed folks to my git repo, but i wanted to explain a bit about this. i think it makes sense to move to a distributed source code model, and i offer to manage the upstream for as long as that is prudent. i explicitly didn't create a sipfoundry git repo because i wanted to make it clear the responsibility ultimately and initially falls on my shoulders to merge your contributions in. This is in direct contrast to a model where contributions are submitted, but no one feels obliged to do anything about accepting it. I can't guarantee I'll get this right, or that i'll be as responsive as we'd all like, but I can promise I'll do my best. Should the community agree I am not fulfilling my duties, a new repo can be declared and builds can start coming from there. Providing the ability to declare a new upstream source tree at any time will make all the difference in ensure there is only one upstream source tree. Knowing that an official source tree is only distinguished from an unofficial one by where the official builds come from. On that front, I've reached out to several non-eZuce employees that have made contributions in the past in regards to building and should they accept the responsibility, they will have all the power to produce the new official builds including ISOs. Matt White has already volunteered, thank you Matt. I feel like this time, we have a chance to get some of these finer details right and I now know it will make all the difference. _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
