This is a interesting conversation. I have been thinking recently about what motivates people to contribute to free software projects. What I have come up with is this: 1. They need it to do _that_. 2. If they contribute code then their contribution will be maintained with the trunk (perhaps even improved), if they try to maintain a patch set in-house, they will be forced to make changes to it each time a new version comes out. IMO this is a big motivator for people to clean up their code and meet project standards.
On 01/27/2011 08:46 AM, Vincent Massol wrote: > Hi Sergiu/everyone, > > See below. > > On Jan 13, 2011, at 9:53 PM, Sergiu Dumitriu wrote: > >> Hi Community, >> >> The following message expresses my personal opinions as a member of the >> community, so it might not be entirely accurate. The goal is to start a >> discussion about how can we attract more contributors and committers to >> the XWiki open source project, and will address three main subjects: >> >> - the current state of the community and committers >> - the possibility of joining or creating a non-profit foundation to >> govern XWiki >> - the possibility of using Fundry as a way for users to fund XWiki >> development >> >> ----- >> Status of the community >> >> At the start of a new year, it's time to look a bit at the status of >> XWiki, the project and the community. >> >> XWiki was created by Ludovic Dubost as an open source project from the >> start. Later, he founded a commercial company (XWiki SAS, back then >> XPertNet SaRL) as a way to financially support the development of the >> product. It kept the project entirely open, unlike the many false open >> source companies that only offer a basic open source version, forcing >> people to buy the commercial one (the open core model), or that only >> release the source code while still doing behind-the-curtains >> development, or that almost completely ignore the outside community. >> >> See the XWiki SAS values: http://purl.org/xwiki/sas-values and >> manifesto: http://purl.org/xwiki/sas-manifesto >> >> The committers, elected for their merit, and not made automatically as >> employees of the company, always tried to maintain a healthy community >> and attract new contributors/committers. Thus, the XWiki software is >> developed not by the XWiki SAS company, but by the XWiki community. >> http://dev.xwiki.org/xwiki/bin/Community/ has a lot of information about >> the community, and the development process. >> >> As of January 2011, there are 16 core committers, 12 of which are XWiki >> SAS employees, and 3 are or were related to XWiki SAS one way or another. >> http://dev.xwiki.org/xwiki/bin/Community/HallOfFame#HCoreCommitters > > I've just updated this page and added an Affiliation column for increased > transparency: > http://dev.xwiki.org/xwiki/bin/view/Community/HallOfFame > >> A big part of the development is aided by non-committer members of the >> community, either by providing patches, testing and reporting bugs, >> requesting new features, providing feedback, answering on the mailing >> lists, etc. As committers, we tried to listen to the community when >> developing the project, but as paid employees we have to also listen to >> the company requirements. With a limited manpower it's very hard to >> evolve as fast as the community would want, or in all the directions >> that the community wants. And we welcome any help here. >> >> The project is healthy, we have regular and frequent releases, with >> visible progress with each new release (see Vincent's statistics on >> http://massol.myxwiki.org/xwiki/bin/Blog/XWikiIn2010 for more details). >> Still, I'm a little disappointed with the development speed. Lately, out >> of the 16 committers on average about 3-4 are actually available for >> platform development during a day. >> >> * How can we help speed up the growth of the community? > > Find a way to sponsor more people? :) > > IMO the community is growing fast. I think you mean the development team > (committership), right? > >> * How can we attract more developers outside XWiki SAS? > > (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. My understanding is Linux recklessly breaks old api at the internal/modular level. Given #2 (top), our tiptoeing through deprecation/migration processes may actually harm us by encouraging people to keep their modifications secret. > > 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. Nobody will want to contribute to a module unless they use it. A question I think we should all be asking is: "I have a server with linux and lighttpd, mysql, php. I have a java vm on the server but it's not being used. I am having a problem with bots signing up automatically. I don't need a wiki, I just need a better captcha engine. What can XWiki do for me, and how can I make that happen from my php registration script?" > > 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&requestId=10191) > 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) A foundation is a good idea if it has a clear goal. Incubating new projects is a great goal but XWiki is not really a new project so I think a foundation for maintaining it would be seen as a bit of a ruse. > 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) The people who will contribute the most back to the source are not those who want to drop a wiki on their desktop and go, they are those who want to mix and match modules with their own and build a totally new project. Git (and more specifically github) has a great advantage that it allows anyone to fork a project easily. I favor hosting each core module in a separate github repository where they can easily be forked, modified, mix-and-matched, real world tested, and proposed for inclusion back into XWiki itself. We also need our ECM to support JSR-330 so that people can use our modules with other dependency injection systems. > 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. Bounties are not something to be taken lightly since there will inevitably be people who feel ripped off and they will have to be heard/arbitrated. An idea along a similar line is an "app store" but since there is no way to make free and open DRM and DRM in general attacks free culture, some creativity would be needed. > > 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 > " > >> ----- >> Joining/forming a free software foundation >> >> One possible reason while so few people are willing to become committers >> could be that XWiki SAS might appear to over-control the software, and a >> clear non-profit foundation on top of XWiki might make it more obvious >> that XWiki is a true open source project, and anybody is welcome to join. Modularity and inviting people to fork (git) will ease any tensions there might be around this. > > 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)... > >> XWiki SAS is a member of the OW2 consortium http://ow2.org/ , and this >> membership also extends a bit to the XWiki project. OW2 used to host all >> our infrastructure, SVN, mailing lists, downloads... Currently only the >> official downloads linked from the main download page are hosted on OW2 >> servers, as we've gradually moved parts of the development >> infrastructure on servers provided by XWiki SAS. >> >> While OW2 is a great home for XWiki SAS, it's mostly a company >> consortium, not a software development foundation. The most development >> help coming from OW2 consists of research projects involving both OW2 >> and XWiki SAS, thus the OW2 membership doesn't bring much value when it >> comes to code. >> >> One option is to form an XWiki non-profit Foundation, which will govern >> all XWiki-related software development. The main disadvantage would be >> that there's a risk that it won't make any difference at all, while >> adding the burden of more paperwork. This is where your opinion comes >> into play, since there's no point in doing all the hard work if the >> community doesn't see a clear benefit in it. > > +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) > >> The Apache Foundation has the huge disadvantage that it requires a >> license change, but it's a very well known home for software >> development, with good visibility. > > 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" > >> The Software Freedom Conservancy has been getting a lot of press >> recently, since several high profile projects joined it. It's got a few >> top-notch projects under its hood, so XWiki would be among well known >> projects in there. > > Would need to check this out, never heard about it. > >> A smaller, compatible alternative is Codehaus, but I'm not convinced >> they would make a difference with respect to our needs. > > Agreed. > >> Other foundations aren't really suited for XWiki, since they either >> don't bring value to the community because they don't foster >> inter-project collaboration (SourceForge, Google Code), or don't match >> the project goals (FSF, GNU, Eclipse, Linux, Mozilla...). > > 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. > >> So, some questions in regard to this subject: >> >> * Is there anybody that would like contribute more / become a committer? >> * Do users believe that a foundation on top of XWiki will help attract >> more developers? >> >> Please note that this is not THE discussion about which foundation to >> join, just trying to see if there is a benefit in doing so. >> >> ----- >> Supporting code development >> >> Becoming a committer requires time, and few people can spend that time >> when there's no direct benefit involved. XWiki SAS employees are already >> being paid to work with XWiki, so they can contribute to the platform >> because the company benefits directly from their work. Employees of >> other companies that deal with XWiki do spend time contributing, but >> very few actually got to hang around enough to be voted as committers, >> although many came close, but stopped short of it. >> >> One way of supporting code development is to contact XWiki SAS and sign >> a contract to develop one or more features with a higher priority. >> >> An alternative, which allows to share the cost with other >> companies/individuals, is to collaboratively request and support feature >> development (crowdfunding), for example through Fundry, a new site >> especially designed for this. I've set up an account for XWiki at >> https://fundry.com/project/58-xwiki . This is also a good place to >> donate to the XWiki project, since there are no visible ways to >> financially support the project. >> >> Fundry would allow to gather financial incentives for non-employees to >> contribute more code, thus involving the community more in the direction >> the software evolves, and attracting more potential contributors. >> >> * Do you (the community) think this is a good idea and it would help? >> * Would you be willing to contribute/donate to the 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 > >> ----- >> >> Please provide us with your feedback, so we can advance on these topics. >> >> Thanks, >> -- >> Sergiu Dumitriu >> http://purl.org/net/sergiu/ > _______________________________________________ > users mailing list > users@xwiki.org > http://lists.xwiki.org/mailman/listinfo/users > _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
