Re: [xwiki-devs] [xwiki-users] State of the XWiki Community

Hi Sergiu/everyone, See below. On Jan 13, 2011, at 9:53 PM, Sergiu Dumitriu wrote: I've just updated this page and added an Affiliation column for increased transparency: http://dev.xwiki.org/xwiki/bin/view/Community/HallOfFame Find a way to sponsor more people? :) IMO the community is growing fast. I think you mean the development team (committership), right? (Here's below a repost to an internal mail where we were discussing about whether the bar is too high or not to contribute to xwiki's development, with slight modifications) " I think we need to separate 2 areas: * core contributions * extension contributions This is the same in all open source project (linux core, vs peripheral things). The level of quality asked is not the same for core contributions vs extension contributions or peripheral domains (non core). I doubt very much that the linux kernel accepts contributions that don't have a very good quality level for example. Same for Firefox or any other Mozilla project. In practice I don't think we can expect people external to XWiki SAS or more generally people not paid to work on XWiki for 2 reasons: 1) there are committers paid to work daily on them and as such they progress much faster than anyone outside could (since those person outside are not paid for that and don't have extensible time - they do it in their free time - it's almost impossible to follow code and discussions). 2) it requires a high quality level I'm always surprised and have a great admiration when people succeed in contributing to core things, like Sergiu in his time, Denis and Caleb. Also I think that most open source project have a very small number of people who are actually core committers (you can count them on one or 2 hands). When you see open source projects with tons of contributors they're actually contributing to peripheral things like: translations, themes, extensions, etc. What I've been trying to organize since I joined the XWiki project is to transform a huge monolithic core into separate domains and submodules in order to make contributing easier. The smaller our core becomes and the larger our extensions become and the easier it'll be to contribute to them IMO. We do care about all contributions but the problem is that if you look at the patches we have in JIRA (there are 40:http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?mode=hide&requ…) the huge majority cannot be applied either because they're too generic, missing tests, have no documentation, etc. The only way to apply them is to spend a considerable amount of time (usually about 3-4 more time than the contributor himself/herself has spent). Should we just commit stuff even if there are no tests, it's not been validated, doesn't follow our best practices, has no documentation, etc? I'd say no since it's increasing our technical debt and we (committers) will have to pay it (it's always paid). So there are several things we can do IMO: 1) architecture improvement: - Continue moving stuff out of xwiki-core into modules and continue making our architecture modular and move things out of the core. - With the upcoming extension manager we'll make a giant leap in that direction since we'll be able to remove bundled extensions from the core and instead allow them to be installed by the user using the extension manager, at runtime. - Add interface extensions so that contributors can contribute UI extensions to XWiki 2) continue reviewing/apply patches when they arrive 3) redesign xwiki.org to make it more participative. See the proposal made for the contrbution area, making contributors more visible (http://incubator.myxwiki.org/xwiki/bin/view/Improvements/XWikiOrgProposal2) 4) improve the dev documentation on xwiki.org for contributors 5) create a foundation (although I'm not sure it'll help attract developers but it's good anyway to have) 6) move to git. This could make it easier for contributors to have their branches easily without having to contribute back work to the project (but the downside is that contributors may feel less tempted to contribute back stuff) 7) continue promoting contrib.xwiki.org which is an area where we accept all contributions without any check 8) set up a bounty system where we advertise bounties. I'm still a bit skeptical about it (since it means we'll need to find committers with the time to review contributions) but there's only one way to find if it could work. Then there are more radical ideas: 9) Join another forge (Eclipse, Apache, Codehaus, etc) 10) Merge with another wiki project (for example jspwiki at apache) 11) find more money to be able to pay for more developers. This could mean accepting donation through the Foundation to pay for bounties for example We could also propose to more contributors to become committers. Do we have people in mind that we think could be committers right now? The only thing I'm personally not ready to do right now (unless convinced otherwise) is to reduce our quality rules and accept any contributions independently of their quality. If some of you think we should do this please raise it and we can discuss it. Brest is to discuss it practice by practice. To be honest I think our quality level is not particularly high. We have lots of commits done without any test for example. Sonar provides a good view of the quality (Globally we seem to be improving on most fronts but not that much): http://nemo.sonarsource.org/dashboard/index/178313 " I don't think this is the case but I may be wrong. IMO it's more that XWiki SAS sponsors a lot of devs to work full time on XWiki dev thus making it less needed for others to contribute to get what they need (they just have to wait for it to become available in the product)... +1 for creating a Foundation for me. It has some advantages: * Clearer separation between XWiki SAS and the XWiki open source project (even though the roles and boundaries are already very clear). It would help for example for Ludovic Dubost (who owns the XWiki mark) to license it to the community) * Ability to accept donations * Have an official entity that we can use in events, marketing messages for the open source project, etc * Ability to have people representing the full ecosystem at the board of the foundation (we'd need to decide on a governance model) Yes visibility would be multiplied x10 but it's has its drawbacks too: * license change * slower pace (when requiring infra softare or machines for example) * more "bureaucratic" Would need to check this out, never heard about it. Agreed. Except potentially merging the XWiki Rendering engine/WikiModel with Eclipse's WikiText project but that's a specific topic in itself. BTW that rendering engine could also be proposed to the ASF too should we want that, we don't have to move the whole XWiki project. +1 for setting up that Foundry/Bounty system from me. Where do the money goes to? Do they handle that (playing the man in the middle)? Thanks -Vincent