Our subversion server should be ready to go now. The old codebase (that was dumped several months ago) is gone, the blender plugin Palle wrote is copied over as is the media directory, and a /trunk/pysoy directory is awaiting the code Zach's team has been working on.
Oh, yea, we're posting to the CIA bot now. Hopefully we can get the bot in #PySoy soon.
Friday, December 29, 2006
Wednesday, December 20, 2006
another re-org update
I've collected comments/concerns from 9 people now and, after a discussion with Zach on these, I've published a revised PySoy Rank proposal
The new proposal eliminates Initiate/Intern votes to remove the "leads/directors can get a bunch of non-involved friends as initiates to swing a vote" loophole. It also changes the ratio between developers to make Leads more powerful and the Maintainer less powerful as follows:
Director term limits are now proposed for 1 year, previously directors could only voluntarily step down or removed through 2/3rd majority, thus giving contributing/lead developers more power to replace directors who do not represent them.
The powers granted to the Maintainer has also been reduced by delegating them to other Directors (which now have named seats and defined responsibility). Ie, the Maintainer cannot unilaterally spend money, handle code packaging, schedule monthly meetings, etc. In many ways the role of Maintainer has been changed to just being an inter-Lead mediator rather than being responsible for the entire codebase.
I think we're getting close to voting on this. Continue to send me comments, comment on the wiki, speak up on IRC, etc.
The new proposal eliminates Initiate/Intern votes to remove the "leads/directors can get a bunch of non-involved friends as initiates to swing a vote" loophole. It also changes the ratio between developers to make Leads more powerful and the Maintainer less powerful as follows:
- contributor -> lead vote ratio from 150% to 200%
- lead -> maintainer vote ratio from 166% to 150%
- board -> maintainer vote ratio from 125% to 100%
Director term limits are now proposed for 1 year, previously directors could only voluntarily step down or removed through 2/3rd majority, thus giving contributing/lead developers more power to replace directors who do not represent them.
The powers granted to the Maintainer has also been reduced by delegating them to other Directors (which now have named seats and defined responsibility). Ie, the Maintainer cannot unilaterally spend money, handle code packaging, schedule monthly meetings, etc. In many ways the role of Maintainer has been changed to just being an inter-Lead mediator rather than being responsible for the entire codebase.
I think we're getting close to voting on this. Continue to send me comments, comment on the wiki, speak up on IRC, etc.
Monday, December 18, 2006
more on the re-org
I'm facilitating the PySoy re-org discussion as Zach has noted his non-neutrality..
In addition to comments from Zach and myself I've heard from 3 developers, two in Zach's current dev team and one who has not been able to contribute recently due to work not being on svn.
Planet PySoy readers click here for more.
In no order, their questions/comments and responses:
Anyone have more questions or concerns? Throw them at me (Arc on Freenode or arc at pysoy) or publically to the pysoy-dev (@ pysoy) list. Don't be shy, you don't have to be a current developer to comment!
In addition to comments from Zach and myself I've heard from 3 developers, two in Zach's current dev team and one who has not been able to contribute recently due to work not being on svn.
Planet PySoy readers click here for more.
In no order, their questions/comments and responses:
- how does this address the issue of one person (maintainer) running everything? (answer from Zach, summarized)
- The maintainer has only limited exclusive control and can be removed if he/she acts irresponsibly. As a member of the board, the maintainer is like a president. The maintainer's vote < (2 * board members | 2 * lead developers | 3 * contributing developers). Zach's idea is to make the maintainer's voice louder than others but not over-poweringly so.
- who decides who will fill the ranks (or how will current developers be ranked)? (answered myself)
- This will not change what role anyone is in, only formalize it. We'll send out an all-call to everyone who's signifigantly contributed to PySoy over the past 6 months to vote on the re-org proposal. If it passes those who voted (yay, nay, or obstain) will be included, those who did not will not be. Those currently interested in contributing, but have not really gotten involved yet, will be paired with a mentor once the re-org is complete.
- why so many ranks (or why not make everyone equal)? (answer from Zach, verbatim)
- I'm afraid that would be counter-productive to a stable, long-lasting pySoy. Ranks are a numerical representation of each developer's contribution level. It's a balence between allowing every developer to be involved in decisions, not having every minor decision have to go up for vote, and having the project remain stable with a single maintainer. It does not mean I view myself as better than others. :)
- why can't an outside group just join to absorb us? (answered myself)
- The mentorship period lets us screen people who are not really interested PySoy beyond it's name recognition
- can't board members cheat votes by mentoring friends just before an election? (answered myself)
- In theory, yes, but this is still better than the current situation where all developers have equal vote but Zach exclusivly controls who can be a developer
- how can a new structure be implemented if/when this one stops working? (from myself, verbatim answer from Zach)
- A `Vote for Change' can be made to replace the Rank structure.
Anyone have more questions or concerns? Throw them at me (Arc on Freenode or arc at pysoy) or publically to the pysoy-dev (@ pysoy) list. Don't be shy, you don't have to be a current developer to comment!
Saturday, December 16, 2006
PySoy, a Historical Perspective
With the reorganization discussion underway and so many people joining over the last few weeks I'd like to present a historical perspective of PySoy and where I see things going.
If you're reading Planet PySoy you can access the full text here. It's far too lengthy for syndication.
So it all starts with a quirky vegetarian college kid in France using the moniker "Jiba".
Jiba likes to design video games. He isn't good at math or programming and wants a way to build 3d games without having to be good at either.
At some point, perhaps in the late 90's, he knows Visual Basic so he writes a 3d engine (in VB) called Soya. Then he learns Java and writes a new engine called Opale.Soya (Soya 0.2?) for Java with his brother, then in 2003 he and his brother rewrote it again for Python calling it Soya 0.3.
This trend continues, Soya is redesigned and rewritten (in various mixes of C, Python, and PyRex) several times with it's API radically changing in each version. Jiba gets a lot of help from his older brother and friends at school with various parts and Jiba releases a few games that use it.
The story would likely end there if Soya didn't attract interest from developers from other parts of Europe and the US. In 2004-2005 one such developer from the UK, going by the moniker "Dunk" or d1223m, joined the Soya group by adding a new widget system called Pudding. During the same time I (Arc Riley) got involved with Soya as I was using it for my GNU project Aetherspace and to teach 3d programming at a community center in upstate NY.
I organized Team Soya during the first PyWeek competition which created a lot of new energy in the Soya project (including Soya's 10.1 release). Shortly after the competition Dunk and Jiba had a falling out after a number of disagreements where Dunk suggested that Soya was designed so haphazardly and so flawed that it needed to be rewritten from scratch.
He took several of the newer developers with him, including all those Soya picked up during the PyWeek competition, and started a new 3d engine project (which fizzled out after a few weeks). His earlier work toward this effort was called Soya 2 or "Evil Soya".
I and a few of the developers who stayed with Soya worked out an agreement with Jiba to transform Soya into a community project to allow Soya to turn into something awesome. This agreement was in exchange for not joining Dunk's project, something Jiba fought to prevent.
Fast forward about 8 months.
We saw no new Soya releases, little contributed code was accepted, and we barely saw or heard from Jiba. It was seeming like the only way for things to move forward was for the rest of us to take a leadership role and make them happen. I registered Soya3d.org as a Trac site (wiki, subversion, tickets, etc) and many of us started using it.
I organized Soya's participation in the Google Summer of Code and, once again, Soya gets a flood of interest from developers (including Jiba). This flood brought a lot of new ideas, many of which Jiba disagreed with, and the "community leadership" agreement we made a year prior turned to dust as Jiba struggled to maintain control against what he perceived as a hijacking of his project.
Emotions were really strong over this. On IRC one night, after an argument, Jiba suggested (perhaps not seriously) we fork Soya. By the time he returned to IRC the next day the PySoy domain (pysoy.org) was registered and the fork was officially announced.
After a heated few days the 2 Summer of Code students were divided as per their mentors; Jiba's local friend Pierre-Yves (marmoute) stayed with Soya and Buddha's (blaisepascal) student Palle (praabjerg) with PySoy.
This unfortunately required employees of Google to sort out as Jiba was demanding both students and organized many of his friends to "rally" for him. Blog entries were written, #PySoy started getting flooded by friends of Jiba, and they petitioned support "in defense" of Soya from the larger Python community.
Issues spanned the range of our use of the word "Soy" being disambiguous with "Soya", who mentored the Summer of Code students, our retention of the Soya3D.org domain for forwarding ticket URLs to pysoy.org, our copying of wiki content and documentation (Jiba claims it was copyright violation since he never freely licensed it), and accusations of malicious server infiltration and domain hijacking.
This became serious enough for several Freenode IRC admins (mainly Rob Levin) to get involved ending in most of France (entire netblocks) banned from #PySoy and moderated on our mailing lists. These policies have continued to date.
With the fork issue finally calming down we went to work. Tasks were divided, discussions were held, issues were sorted out. Several former Soya developers, hearing about the fork from all the noise Jiba's friends were kicking up, joined us.
Zach became the maintainer and I, after getting distracted with other projects, stayed on to manage the website and any business matters that came up.
In my perspective, Zach was a bit intimidated by the lack of structure. We run by democracy, great, but who votes? How? When? Where? Does this mean some guy just joining is counted equally as someone who's poured their heart and soul into the project for a year? Or does it mean only people we hand-pick get to vote?
The result of this, as I see it, was a move toward insularization. Democracy, yes, but only within a closed group with membership limited to trusted developers. IRC stopped happening, the website stopped being used, the mailing list went silent, subversion updates slowed, even blogs were only updated when I asked something be posted.
This wasn't what any of us wanted to see but it kept chaos at bay in lack of any other structure, and productive work was being done, so this is the way it's been for months now.
The team Zach organized reached the same assessment (unanimously?) that Dunk reached the previous year; it would be easier to write a new engine from scratch than fix Soya even after most of the API was cleaned up. Doing so would also clear up a sticky legal situation with Jiba holding a copyright on much of the code and being unwilling/unable to defend the GPL in court.
We like the general idea of Soya - Jiba was brilliant in some of his ideas on how to abstract OpenGL behavior to a high level language such as Python. It's implementation that he fell short on.
Building an engine from scratch was a much larger scope than we started with. On one hand every release goal was getting thrown away, it has taken months (and will take many more) to get a working release out. On the other hand, PySoy will be faster and easier to work with as a result.
Although Zach was in support of this he was obviously becoming overwhelmed. On top of being the chief architect and maintainer of PySoy he had people emailing him, wanting to get involved, and helping them get started. He apparently also had several new people making commitments, contributing some code, then disappearing before they finished.
In the last two weeks alone I've seen 8 versions of the phrase "it would have been faster/easier for me do it myself" in emails from Zach as entire source files contributed by absent developers got nixed or rewritten. I'd have to say he's contributed roughly 3/4 of the current codebase himself, much of that code a new developer promised to do and dropped the ball on.
Three days go I got an email from Zach that sounded like he was quitting as maintainer, two others CC'ed on that email thought the same thing. In response to my request for clarification he proposed what we're now calling the "Rank" system.
While I have reservations with some elements of the rank proposal (and some of my concerns have been addressed), overall, I think this is a really healthy direction to move in. It's certainly in the spirit that PySoy was created.
I think a bit of perspective is needed, however, as we discuss it.
Even once implemented it's not set in stone. If we implement it and it doesn't work, or stops working, we'll modify it or try something entirely different. The question is not "will this work for us forever". We don't need to craft a structure that will scale from a dozen developers to several hundred.
The question is, simply, "will this work for us right now".
The PySoy community has adapted, and will continue to adapt, to our current needs just as it has over the past 3+ years. All we need for now is a structure to get through the first release cycle. We'll adapt it as needed.
If you're reading Planet PySoy you can access the full text here. It's far too lengthy for syndication.
So it all starts with a quirky vegetarian college kid in France using the moniker "Jiba".
Jiba likes to design video games. He isn't good at math or programming and wants a way to build 3d games without having to be good at either.
At some point, perhaps in the late 90's, he knows Visual Basic so he writes a 3d engine (in VB) called Soya. Then he learns Java and writes a new engine called Opale.Soya (Soya 0.2?) for Java with his brother, then in 2003 he and his brother rewrote it again for Python calling it Soya 0.3.
This trend continues, Soya is redesigned and rewritten (in various mixes of C, Python, and PyRex) several times with it's API radically changing in each version. Jiba gets a lot of help from his older brother and friends at school with various parts and Jiba releases a few games that use it.
The story would likely end there if Soya didn't attract interest from developers from other parts of Europe and the US. In 2004-2005 one such developer from the UK, going by the moniker "Dunk" or d1223m, joined the Soya group by adding a new widget system called Pudding. During the same time I (Arc Riley) got involved with Soya as I was using it for my GNU project Aetherspace and to teach 3d programming at a community center in upstate NY.
I organized Team Soya during the first PyWeek competition which created a lot of new energy in the Soya project (including Soya's 10.1 release). Shortly after the competition Dunk and Jiba had a falling out after a number of disagreements where Dunk suggested that Soya was designed so haphazardly and so flawed that it needed to be rewritten from scratch.
He took several of the newer developers with him, including all those Soya picked up during the PyWeek competition, and started a new 3d engine project (which fizzled out after a few weeks). His earlier work toward this effort was called Soya 2 or "Evil Soya".
I and a few of the developers who stayed with Soya worked out an agreement with Jiba to transform Soya into a community project to allow Soya to turn into something awesome. This agreement was in exchange for not joining Dunk's project, something Jiba fought to prevent.
Fast forward about 8 months.
We saw no new Soya releases, little contributed code was accepted, and we barely saw or heard from Jiba. It was seeming like the only way for things to move forward was for the rest of us to take a leadership role and make them happen. I registered Soya3d.org as a Trac site (wiki, subversion, tickets, etc) and many of us started using it.
I organized Soya's participation in the Google Summer of Code and, once again, Soya gets a flood of interest from developers (including Jiba). This flood brought a lot of new ideas, many of which Jiba disagreed with, and the "community leadership" agreement we made a year prior turned to dust as Jiba struggled to maintain control against what he perceived as a hijacking of his project.
Emotions were really strong over this. On IRC one night, after an argument, Jiba suggested (perhaps not seriously) we fork Soya. By the time he returned to IRC the next day the PySoy domain (pysoy.org) was registered and the fork was officially announced.
After a heated few days the 2 Summer of Code students were divided as per their mentors; Jiba's local friend Pierre-Yves (marmoute) stayed with Soya and Buddha's (blaisepascal) student Palle (praabjerg) with PySoy.
This unfortunately required employees of Google to sort out as Jiba was demanding both students and organized many of his friends to "rally" for him. Blog entries were written, #PySoy started getting flooded by friends of Jiba, and they petitioned support "in defense" of Soya from the larger Python community.
Issues spanned the range of our use of the word "Soy" being disambiguous with "Soya", who mentored the Summer of Code students, our retention of the Soya3D.org domain for forwarding ticket URLs to pysoy.org, our copying of wiki content and documentation (Jiba claims it was copyright violation since he never freely licensed it), and accusations of malicious server infiltration and domain hijacking.
This became serious enough for several Freenode IRC admins (mainly Rob Levin) to get involved ending in most of France (entire netblocks) banned from #PySoy and moderated on our mailing lists. These policies have continued to date.
With the fork issue finally calming down we went to work. Tasks were divided, discussions were held, issues were sorted out. Several former Soya developers, hearing about the fork from all the noise Jiba's friends were kicking up, joined us.
Zach became the maintainer and I, after getting distracted with other projects, stayed on to manage the website and any business matters that came up.
In my perspective, Zach was a bit intimidated by the lack of structure. We run by democracy, great, but who votes? How? When? Where? Does this mean some guy just joining is counted equally as someone who's poured their heart and soul into the project for a year? Or does it mean only people we hand-pick get to vote?
The result of this, as I see it, was a move toward insularization. Democracy, yes, but only within a closed group with membership limited to trusted developers. IRC stopped happening, the website stopped being used, the mailing list went silent, subversion updates slowed, even blogs were only updated when I asked something be posted.
This wasn't what any of us wanted to see but it kept chaos at bay in lack of any other structure, and productive work was being done, so this is the way it's been for months now.
The team Zach organized reached the same assessment (unanimously?) that Dunk reached the previous year; it would be easier to write a new engine from scratch than fix Soya even after most of the API was cleaned up. Doing so would also clear up a sticky legal situation with Jiba holding a copyright on much of the code and being unwilling/unable to defend the GPL in court.
We like the general idea of Soya - Jiba was brilliant in some of his ideas on how to abstract OpenGL behavior to a high level language such as Python. It's implementation that he fell short on.
Building an engine from scratch was a much larger scope than we started with. On one hand every release goal was getting thrown away, it has taken months (and will take many more) to get a working release out. On the other hand, PySoy will be faster and easier to work with as a result.
Although Zach was in support of this he was obviously becoming overwhelmed. On top of being the chief architect and maintainer of PySoy he had people emailing him, wanting to get involved, and helping them get started. He apparently also had several new people making commitments, contributing some code, then disappearing before they finished.
In the last two weeks alone I've seen 8 versions of the phrase "it would have been faster/easier for me do it myself" in emails from Zach as entire source files contributed by absent developers got nixed or rewritten. I'd have to say he's contributed roughly 3/4 of the current codebase himself, much of that code a new developer promised to do and dropped the ball on.
Three days go I got an email from Zach that sounded like he was quitting as maintainer, two others CC'ed on that email thought the same thing. In response to my request for clarification he proposed what we're now calling the "Rank" system.
While I have reservations with some elements of the rank proposal (and some of my concerns have been addressed), overall, I think this is a really healthy direction to move in. It's certainly in the spirit that PySoy was created.
I think a bit of perspective is needed, however, as we discuss it.
Even once implemented it's not set in stone. If we implement it and it doesn't work, or stops working, we'll modify it or try something entirely different. The question is not "will this work for us forever". We don't need to craft a structure that will scale from a dozen developers to several hundred.
The question is, simply, "will this work for us right now".
The PySoy community has adapted, and will continue to adapt, to our current needs just as it has over the past 3+ years. All we need for now is a structure to get through the first release cycle. We'll adapt it as needed.
Wednesday, December 13, 2006
site fixed
A trac upgrade rendered much of the PySoy site unusable for a time, all fixed up now.
There's a fix to the pydoc plugin pending the new docs load. Everyone should know by now that the work Zach and the team are doing obsoletes what's currently there.
Let me know if there's any further issues with the site.
There's a fix to the pydoc plugin pending the new docs load. Everyone should know by now that the work Zach and the team are doing obsoletes what's currently there.
Let me know if there's any further issues with the site.
Subscribe to:
Posts (Atom)