Personally, I like the contribution model Google has in place for FedOne. Yes, the bar is higher than a Wiki, but it is similar to some open source projects and is lower than any proprietary or "shared source" model. Since Google's name is on the project they wish to maintain high quality and ensure that any changes are in line with their vision. That seems reasonable to me. They have invited people to build their own implementations, and there is nothing stopping people from forking FedOne and going their own direction with it.
As for the specs, I imagine that at some point these will be submitted to the IETF or similar for standardization, and at that time a committee will be formed. I personally, would not want to have to develop a standard using a wiki. Open to contributions, yes; anyone can edit, no. The current anyone-can-submit-for-review-before-inclusion model seems like an appropriate balance between the near-anarchy of a Wiki and the iron curtain of proprietary software. As for code changes, I found the code review process was reasonable. The commits with my changes have my name on them. That's sufficient credit for me at this time. If I made a larger contribution (say adding DB based persistence) then I might want my name on the projects list of contributors. But that's not necessary, or even appropriate, at the moment. -Tad On Sun, Feb 14, 2010 at 9:39 AM, Torben Weis <[email protected]> wrote: > Hi, > >> The barrier for contributing to this is higher than it would be with a >> wiki; but for specifications and similar documents, this is probably a >> good thing. Please send your contributions through the usual code >> review channels. We would like to see the errors that you found >> fixed. > > I submitted an updated federation spec for code review. I am sure that there > are more issues that I have forgotten about. In addition, I inserted a few > comments. In some places FedOne behavior is not in sync with the spec and I > am not sure whose fault this is, i.e. spec or FedOne. I hope you find the > patch or parts of it useful. > As a general side note: In the KDE project we could deal with people > submitting without review. The responsible project owner had to review > changes of newbies as they appeared in the SVN. Large or fundamental changes > had to be discussed on mailing lists before they were committed. If a > submitter messed things up (which happened), he got a slap on his fingers. > If that did not help, SVN access could be removed (although I cannot > remember a case where this has happened). All it takes is a project owner > who has a look on changes done by new developers. I like this optimistic > model more, because it allows the project to move fast. But wave uses a > pessimistic model which is more company-style and less > open-source-project-style. Looking at the codereview web site I see a 3 week > old patch of James still pending. That is not really encouraging, is it? > Furthermore,. the contributors are not listed prominently. For example Tad > Glines did a useful patch for me but his name is hard to find at all. If > Google really wants to run an open source project. someone should rethink > the modus operandi. Now, I promise that this was my last comment on this > issue :-) > Cheers > Torben > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
