[xwiki-devs] An appeal for insight into the development of XWiki
Dear developers of XWiki! I am a student of Software Engineering at the Vienna University of Technology and currently writing my master thesis on project management and the development methods used in open source projects. In my research I analyzed open source development and compared it with elements found in various proprietary approaches, both agile and well-defined. But to provide balanced and up-to-date results my work relies on first- hand information and expert opinion, for which I need your help. XWiki matches my criteria regarding size, activity and available information and I would be glad to include it in my case study. I am looking for an interview partner with good insight into the project structure and a solid overview of all stages of development, ideally a member of the core team with long-term dedication to the project. The interview would take about 20 minutes on Skype (or a similar phone- based tool). If you prefer a written chat, that can be arranged as well. My daily schedule is flexible, so whatever time suits you best should work for me. The subject areas I would like to cover in the interview are XWiki's: * Development flow and release cycles * Social structures, responsibilities and decision making * Code structure and architectural considerations * Special conditions caused by the open source environment I realize your time might be scarce, but if you decide to contribute to this case study your help shall be all the more appreciated. Once finished I will gladly share my results and any new insights gained on the topic with you. Kind regards, Martin Schönberger ([email protected])
Hi Martin, On Apr 12, 2012, at 4:23 AM, Martin Schönberger wrote:
Dear developers of XWiki!
I am a student of Software Engineering at the Vienna University of Technology and currently writing my master thesis on project management and the development methods used in open source projects. In my research I analyzed open source development and compared it with elements found in various proprietary approaches, both agile and well-defined.
But to provide balanced and up-to-date results my work relies on first- hand information and expert opinion, for which I need your help. XWiki matches my criteria regarding size, activity and available information and I would be glad to include it in my case study.
I am looking for an interview partner with good insight into the project structure and a solid overview of all stages of development, ideally a member of the core team with long-term dedication to the project.
We work as a team here on this project so I propose that when you have a question you send it to the list and we'll answer it. Unless some committers want to chat privately with you of course but it would be better for information dissemination that it happens in the open. Hey you've learnt the first lesson of our project: do everything in the open! ;)
The interview would take about 20 minutes on Skype (or a similar phone- based tool). If you prefer a written chat, that can be arranged as well. My daily schedule is flexible, so whatever time suits you best should work for me.
The subject areas I would like to cover in the interview are XWiki's:
* Development flow and release cycles * Social structures, responsibilities and decision making * Code structure and architectural considerations * Special conditions caused by the open source environment
All this is documented already at http://dev.xwiki.org Have you taken the time to read it yet? I suggest you read it first, then if you still have question, ask them here and we'll be glad to answer them or complete our documentation. Good luck in your study and thanks for picking XWiki! -Vincent
I realize your time might be scarce, but if you decide to contribute to this case study your help shall be all the more appreciated. Once finished I will gladly share my results and any new insights gained on the topic with you.
Kind regards,
Martin Schönberger ([email protected]) _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hello Vincent, Thank you for your swift response! I took my time and re-read the developer-section of XWiki in its entirety, and I have to admit the data provided there is quite extensive. But then again, this was one of the reasons this project caught my eye in the first place. Maybe my wording was a bit unfortunate when I described the topics I'd like to discuss. In using the available information about the process as a basis, I would like to go deeper with my questions, talking about background, personal experience, exceptions and the development of the process over time. In the case of XWiki, I'd also be particularly interested in the relationship between the Open Source development methods advocated on xwiki.org and the corporate structure of XWiki SAS. I chose the method of semi-structured qualitative interviews instead of a standardized survey or the analysis of available data because it is responsive, adaptable and allows for immediate feedback - and I'm a bit hesitant of spamming the developer mailing list with a series of questions and follow-ups. That's why I suggested a one-on-one talk - I did not intend any secrecy, and would of course disseminate the outcome of the conversation back to the community. But either way works for me. If you are (or anyone else is) still willing to answer my questions, I can also ask them here in this thread, if you prefer so. Kind regards, Martin
Hi Martin, On Apr 14, 2012, at 8:55 PM, Martin Schönberger wrote:
Hello Vincent,
Thank you for your swift response! I took my time and re-read the developer-section of XWiki in its entirety, and I have to admit the data provided there is quite extensive. But then again, this was one of the reasons this project caught my eye in the first place.
Cool
Maybe my wording was a bit unfortunate when I described the topics I'd like to discuss. In using the available information about the process as a basis, I would like to go deeper with my questions, talking about background, personal experience, exceptions and the development of the process over time. In the case of XWiki, I'd also be particularly interested in the relationship between the Open Source development methods advocated on xwiki.org and the corporate structure of XWiki SAS.
Yep that's interesting. BTW some information about XWiki SAS and the XWiki open source project: * http://www.xwiki.com/xwiki/bin/view/Company/Manifesto and http://www.xwiki.com/xwiki/bin/view/Company/WhoWeAre?language=en * 2008: http://massol.myxwiki.org/xwiki/bin/view/Blog/XWikiSASAndOpenSource * http://markmail.org/message/3mpyhk6u5addevag
I chose the method of semi-structured qualitative interviews instead of a standardized survey or the analysis of available data because it is responsive, adaptable and allows for immediate feedback - and I'm a bit hesitant of spamming the developer mailing list with a series of questions and follow-ups. That's why I suggested a one-on-one talk - I did not intend any secrecy, and would of course disseminate the outcome of the conversation back to the community. But either way works for me. If you are (or anyone else is) still willing to answer my questions, I can also ask them here in this thread, if you prefer so.
Well I'm fine with both too but I really think you'll get more extensive result from asking on this thread: * you'll get the sum of our knowledge. There isn't a single person who knows it all here. We all have some knowledge of some part of XWiki and we don't always agree! (which is very fine) * this interaction will be archived and searchable in the future so people won't just see the result but the whole interaction and the various answers from different people So I'm all for doing it here :) I'd suggest you structure your questions by sending a few questions, let it simmer for several days, discuss it. Then once it settles ask a few more questions, etc. I don't know how many questions you have but if you ask too many at once there's the risk that you won't get answers to all. Anyway feel free to do it the way you want! :) Thanks -Vincent
2012/4/14 Vincent Massol <[email protected]>:
Well I'm fine with both too but I really think you'll get more extensive result from asking on this thread: * you'll get the sum of our knowledge. There isn't a single person who knows it all here. We all have some knowledge of some part of XWiki and we don't always agree! (which is very fine) * this interaction will be archived and searchable in the future so people won't just see the result but the whole interaction and the various answers from different people
So I'm all for doing it here :)
Well, consider me convinced. :) Let's try this the open source way then! Everyone is very welcome to join in on the conversation. As Vincent suggested I am going to split up my questions into three or four posts, roughly separated by topic. This first post contains rather general questions about the process and the stages of development, while the follow-up posts concentrate more on the project's management, people, structure and infrastructure. You can assume that I am aware of the development process as far as it is detailed on dev.xwiki.org and xwiki.com, and for my research I would like deepen this knowledge, especially on how the process is applied in practice, and how it is seen from within. So, without further ado, my first questions: As far as the process is concerned directly, which are the parts of development that profit most from the fact that XWiki is open source? It seems like XWiki has a rather large core team closely working together, and the Hall of Fame lists rather few external contributors. Does this reflect the actual distribution in the project? What are the costs and benefits of using open source development methods in this situation? Would communication patterns, knowledge management and development cycles be approached differently if XWiki was developed purely in-house? Another thing I'm interested in is how the scope of the project and the direction of development are decided on. To what degree do different stakeholders influence the course of XWiki, what is caused by personal itches of the developers, requests of paying customers, or complaints and suggestions of casual users? Is there a special time in the release cycle when new content is agreed upon? How far and in what detail can the content of future releases be planned ahead by the developers? Are detailed plans desirable, or is it more advantageous to react to circumstances when they arise? The third question concerns specialized tasks surrounding the development. XWiki follows diverse strategies for testing. One of them is manual, formal testing executed by a dedicated QA team. Does this part of the approach make the many-eyeballs-method of discovering bugs less important, or is a combination of these two strategies necessary for overall high quality of the code? Could automated testing stand on its with sufficient coverage? On a similar note, how do the different methods pursued in customer support (like detailed documentation, peers helping each other, and specialized paid support) interact and draw upon each other? I phrased the questions deliberately at length to roughly stake out the areas I would be more interested in. Every comment, opinion or experience that relates to the given topics is highly welcome. I will eagerly keep track of the mailing list for answers and follow up with the next round of my questions in a few days. Kind regards, Martin
On Fri, Apr 20, 2012 at 9:43 PM, Martin Schönberger <[email protected]>wrote:
2012/4/14 Vincent Massol <[email protected]>:
Well I'm fine with both too but I really think you'll get more extensive result from asking on this thread: * you'll get the sum of our knowledge. There isn't a single person who knows it all here. We all have some knowledge of some part of XWiki and we don't always agree! (which is very fine) * this interaction will be archived and searchable in the future so people won't just see the result but the whole interaction and the various answers from different people
So I'm all for doing it here :)
Well, consider me convinced. :) Let's try this the open source way then! Everyone is very welcome to join in on the conversation.
As Vincent suggested I am going to split up my questions into three or four posts, roughly separated by topic. This first post contains rather general questions about the process and the stages of development, while the follow-up posts concentrate more on the project's management, people, structure and infrastructure.
You can assume that I am aware of the development process as far as it is detailed on dev.xwiki.org and xwiki.com, and for my research I would like deepen this knowledge, especially on how the process is applied in practice, and how it is seen from within.
Hi Martin,
So, without further ado, my first questions:
As far as the process is concerned directly, which are the parts of development that profit most from the fact that XWiki is open source?
Regarding this topic there is also a blog series written by Ludovic where you can find some of the answers from the company perspective http://www.xwiki.com/xwiki/bin/view/Blog/XWikiVisionOpenSource
It seems like XWiki has a rather large core team closely working together, and the Hall of Fame lists rather few external contributors. Does this reflect the actual distribution in the project? What are the costs and benefits of using open source development methods in this situation? Would communication patterns, knowledge management and development cycles be approached differently if XWiki was developed purely in-house?
Regarding the other questions all that I can say is that I would love to have much more external contributors. Some of us start as independent contributors and get into the company, others work for companies related to XWiki and give back to the community in a form or another (tests, bug reports, improvements requests, community feedback and help, translations, documentation, etc.) The Hall of Fame reflect just long time participants, but the sum of all contributions should be made with all the users from l10n.xwiki.org; jira.xwiki.org; github.com/xwiki; xwiki.org, etc. In my case, first I contributed to XWiki as a GSOC student and after that period I was offered a position inside the company. And I am not the only case, same happend for other GSOC students like Eduard, Ana-Maria, Asiri, Sergiu, etc. So IMO getting from an external contributor to an internal one is great.
From my perspective (as an Interaction Designer) is great that I can work in an open source environment. I get to receive issues (bugs) reports from all over the world, I can ask our users what improvements they would like to see and what they think of my proposals. Sometimes is very hard to make everyone happy, but since I am the only one in the company that is responsible with this topic, if we didn't have this open environment it would be impossible to do my work: being in a remote team and being without a way to reach the users and learn what they need, I couldn't know what to do. Also, being in the open I can reference my work and get critics on it (and I would love an even bigger community so that I could learn even more things).
Another thing I'm interested in is how the scope of the project and the direction of development are decided on. To what degree do different stakeholders influence the course of XWiki, what is caused by personal itches of the developers, requests of paying customers, or complaints and suggestions of casual users? Is there a special time in the release cycle when new content is agreed upon? How far and in what detail can the content of future releases be planned ahead by the developers? Are detailed plans desirable, or is it more advantageous to react to circumstances when they arise?
Our development is made in release cycles. We do one cycle per year (for example we are now developing the 4.x cycle and we just released 4.0, so now we work on 4.1, etc.) In one year we get to have about 6 major releases per cycle (4.0-4.5). For each major release we have a Roadmap meeting, before the release starts, where we decide on what we work on. Check out http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap For each roadmap we vote on the mailing list the issues we work on, the release dates, we vote if we need to delay a bit the release because of certain problems, etc. So the decisions are transparent and everyone can give their opinion on them and interfere. A very-very important aspect is that we do timeboxing releases instead of feature-driven releases so this IMO is a big differentiator between being an open source company and a closed source one (and wait indefinitely for a certain feature). Read more about at http://xwiki.markmail.org/thread/s5wajg23uhqmtnyh Another important aspect is that even if we are a company, we have very clear departments. We have a clear difference between who is working with our paying customers (Clients Team) and who is working for the platform (Tech Team). So even if we collaborate inside the departments we have different purposes and different stakeholders. For the Tech Team the most important stakeholder is the community. Of course we care about what the Clients Team asks, but IMO we consider them as part of the community and as XWiki users (the only difference is that maybe their complains reach faster since this complains can be made in person).
The third question concerns specialized tasks surrounding the development. XWiki follows diverse strategies for testing. One of them is manual, formal testing executed by a dedicated QA team. Does this part of the approach make the many-eyeballs-method of discovering bugs less important, or is a combination of these two strategies necessary for overall high quality of the code? Could automated testing stand on its with sufficient coverage? On a similar note, how do the different methods pursued in customer support (like detailed documentation, peers helping each other, and specialized paid support) interact and draw upon each other?
Regarding this question, I just want to say that we are a small team. We have just a single person as a dedicated QA so all the help he can get is welcomed. For example, I test and report a lot of issues/improvements even though I am not part of the QA team. Another thing is that XWiki is multi OS, multi browser, multi database, multi display, multi whatever compatible :) We always need more eyes, hands, automated tests, manual tests, any kind of tests to verify the quality and then ... we always need more committers to fix them. Hope this helps, Caty
I phrased the questions deliberately at length to roughly stake out the areas I would be more interested in. Every comment, opinion or experience that relates to the given topics is highly welcome. I will eagerly keep track of the mailing list for answers and follow up with the next round of my questions in a few days.
Kind regards, Martin _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, May 3, 2012 at 9:32 PM, Ecaterina Moraru (Valica) <[email protected]
wrote:
On Fri, Apr 20, 2012 at 9:43 PM, Martin Schönberger <[email protected]
wrote:
2012/4/14 Vincent Massol <[email protected]>:
Well I'm fine with both too but I really think you'll get more extensive result from asking on this thread: * you'll get the sum of our knowledge. There isn't a single person who knows it all here. We all have some knowledge of some part of XWiki and we don't always agree! (which is very fine) * this interaction will be archived and searchable in the future so people won't just see the result but the whole interaction and the various answers from different people
So I'm all for doing it here :)
Well, consider me convinced. :) Let's try this the open source way then! Everyone is very welcome to join in on the conversation.
As Vincent suggested I am going to split up my questions into three or four posts, roughly separated by topic. This first post contains rather general questions about the process and the stages of development, while the follow-up posts concentrate more on the project's management, people, structure and infrastructure.
You can assume that I am aware of the development process as far as it is detailed on dev.xwiki.org and xwiki.com, and for my research I would like deepen this knowledge, especially on how the process is applied in practice, and how it is seen from within.
Hi Martin,
So, without further ado, my first questions:
As far as the process is concerned directly, which are the parts of development that profit most from the fact that XWiki is open source?
Regarding this topic there is also a blog series written by Ludovic where you can find some of the answers from the company perspective http://www.xwiki.com/xwiki/bin/view/Blog/XWikiVisionOpenSource
It seems like XWiki has a rather large core team closely working together, and the Hall of Fame lists rather few external contributors. Does this reflect the actual distribution in the project? What are the costs and benefits of using open source development methods in this situation? Would communication patterns, knowledge management and development cycles be approached differently if XWiki was developed purely in-house?
Regarding the other questions all that I can say is that I would love to have much more external contributors. Some of us start as independent contributors and get into the company, others work for companies related to XWiki and give back to the community in a form or another (tests, bug reports, improvements requests, community feedback and help, translations, documentation, etc.) The Hall of Fame reflect just long time participants, but the sum of all contributions should be made with all the users from l10n.xwiki.org; jira.xwiki.org; github.com/xwiki; xwiki.org, etc.
In my case, first I contributed to XWiki as a GSOC student and after that period I was offered a position inside the company. And I am not the only case, same happend for other GSOC students like Eduard, Ana-Maria, Asiri, Sergiu, etc. So IMO getting from an external contributor to an internal one is great.
From my perspective (as an Interaction Designer) is great that I can work in an open source environment. I get to receive issues (bugs) reports from all over the world, I can ask our users what improvements they would like to see and what they think of my proposals. Sometimes is very hard to make everyone happy, but since I am the only one in the company that is responsible with this topic, if we didn't have this open environment it would be impossible to do my work: being in a remote team and being without a way to reach the users and learn what they need, I couldn't know what to do. Also, being in the open I can reference my work and get critics on it (and I would love an even bigger community so that I could learn even more things).
Another thing I'm interested in is how the scope of the project and the direction of development are decided on. To what degree do different stakeholders influence the course of XWiki, what is caused by personal itches of the developers, requests of paying customers, or complaints and suggestions of casual users? Is there a special time in the release cycle when new content is agreed upon? How far and in what detail can the content of future releases be planned ahead by the developers? Are detailed plans desirable, or is it more advantageous to react to circumstances when they arise?
Our development is made in release cycles. We do one cycle per year (for example we are now developing the 4.x cycle and we just released 4.0, so now we work on 4.1, etc.) In one year we get to have about 6 major releases per cycle (4.0-4.5). For each major release we have a Roadmap meeting, before the release starts, where we decide on what we work on. Check out http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap
For each roadmap we vote on the mailing list the issues we work on, the release dates, we vote if we need to delay a bit the release because of certain problems, etc. So the decisions are transparent and everyone can give their opinion on them and interfere. A very-very important aspect is that we do timeboxing releases instead of feature-driven releases so this IMO is a big differentiator between being an open source company and a closed source one (and wait indefinitely for a certain feature). Read more about at http://xwiki.markmail.org/thread/s5wajg23uhqmtnyh
Another important aspect is that even if we are a company, we have very clear departments. We have a clear difference between who is working with our paying customers (Clients Team) and who is working for the platform (Tech Team). So even if we collaborate inside the departments we have different purposes and different stakeholders. For the Tech Team the most important stakeholder is the community. Of course we care about what the Clients Team asks, but IMO we consider them as part of the community and as XWiki users (the only difference is that maybe their complains reach faster since this complains can be made in person).
The third question concerns specialized tasks surrounding the development. XWiki follows diverse strategies for testing. One of them is manual, formal testing executed by a dedicated QA team. Does this part of the approach make the many-eyeballs-method of discovering bugs less important, or is a combination of these two strategies necessary for overall high quality of the code? Could automated testing stand on its with sufficient coverage? On a similar note, how do the different methods pursued in customer support (like detailed documentation, peers helping each other, and specialized paid support) interact and draw upon each other?
Regarding this question, I just want to say that we are a small team. We have just a single person as a dedicated QA so all the help he can get is welcomed. For example, I test and report a lot of issues/improvements even though I am not part of the QA team. Another thing is that XWiki is multi OS, multi browser, multi database, multi display, multi whatever compatible :) We always need more eyes, hands, automated tests, manual tests, any kind of tests to verify the quality and then ... we always need more committers to fix them.
Hope this helps, Caty
Yes, as Caty and Guillaume said, the more eyes are looking, the better the Quality of the product is. I am the QA responsible of testing XE and XEM, but a lot of other bugs are reported by the community. We have a formal Manual Test Plan, you can check http://www.xwiki.org/xwiki/bin/view/TestReports/WebHome . Besides this, we have also an automated tests suite maintained by tech team. We don't have a dedicated team for Testing Automation. For example, there are certain things I always look for, for example: cross-browser compatibility, database migration, etc. The role of the community is important because we have a lot of extensions or use cases which we don't have time/resources to test, but the users which installs them write on the mailing lists, report issues or even provide patches if they find bugs. Usually when a user from mailing lists has troubles accomplishing what he/she wants, we check if that is a valid use case, our developers being very responsive in aiding them. If the use case is valid, this usually goes documented in the according place, so other users wanting to do that, won't have to write on the lists. So the QA is done collaboratively, not only by a dedicated team or individual. Hope this helps.
Regards, Sorin B.
I phrased the questions deliberately at length to roughly stake out the areas I would be more interested in. Every comment, opinion or experience that relates to the given topics is highly welcome. I will eagerly keep track of the mailing list for answers and follow up with the next round of my questions in a few days.
Kind regards, Martin _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Martin, here's my reply as well. Please see my answers below. On Fri, Apr 20, 2012 at 8:43 PM, Martin Schönberger <[email protected]>wrote:
2012/4/14 Vincent Massol <[email protected]>:
Well I'm fine with both too but I really think you'll get more extensive result from asking on this thread: * you'll get the sum of our knowledge. There isn't a single person who knows it all here. We all have some knowledge of some part of XWiki and we don't always agree! (which is very fine) * this interaction will be archived and searchable in the future so people won't just see the result but the whole interaction and the various answers from different people
So I'm all for doing it here :)
Well, consider me convinced. :) Let's try this the open source way then! Everyone is very welcome to join in on the conversation.
As Vincent suggested I am going to split up my questions into three or four posts, roughly separated by topic. This first post contains rather general questions about the process and the stages of development, while the follow-up posts concentrate more on the project's management, people, structure and infrastructure.
You can assume that I am aware of the development process as far as it is detailed on dev.xwiki.org and xwiki.com, and for my research I would like deepen this knowledge, especially on how the process is applied in practice, and how it is seen from within.
So, without further ado, my first questions:
As far as the process is concerned directly, which are the parts of development that profit most from the fact that XWiki is open source?
We get plenty of testing of all parts of XWiki from plenty of people, some of whom contribute specific fixes that would otherwise not be worked on.
It seems like XWiki has a rather large core team closely working together, and the Hall of Fame lists rather few external contributors. Does this reflect the actual distribution in the project?
Yes and no. Sure, most full-time XWiki developers are paid by XWiki SAS, but it's also because the company went to hire active community members. There are also some former employees who are still contributors although no longer employed by XWiki SAS.
What are the costs and benefits of using open source development methods in this situation? Would communication patterns, knowledge management and development cycles be approached differently if XWiki was developed purely in-house?
Not really. The same processes would be used, only limited to internal mailing lists.
Another thing I'm interested in is how the scope of the project and the direction of development are decided on. To what degree do different stakeholders influence the course of XWiki, what is caused by personal itches of the developers, requests of paying customers, or complaints and suggestions of casual users?
All of those factors play a role. Some customers pay for the development of very specific features or extensions. For instance, the Office document Import feature was paid for by a client. There is an internal roadmap process at XWiki SAS where stakeholders from every department can voice their priorities (sysadmin, dev, project management, sales, marketing, research...). Once this has been done, a roadmap is proposed, that members of the Open-Source community can add to if they wish. In addition to this, about 40-50% of the time of core developers is preserved so that they work on maintenance and bug fixing tasks, which they choose what to spend on.
Is there a special time in the release cycle when new content is agreed upon? How far and in what detail can the content of future releases be planned ahead by the developers? Are detailed plans desirable, or is it more advantageous to react to circumstances when they arise?
Given the very frequent release cycle, meetings take place often. There is a new large release every year, interspersed by major releases every 2-3 months. There is a roadmap meeting for each of those, thus it's easy to gather feedback and make priorities evolve along the way. For a large release, a theme and a sub-theme are agreed on that set the general direction of that release. For major releases, a list of JIRA tasks is agreed on. The third question concerns specialized tasks surrounding the
development. XWiki follows diverse strategies for testing. One of them is manual, formal testing executed by a dedicated QA team. Does this part of the approach make the many-eyeballs-method of discovering bugs less important, or is a combination of these two strategies necessary for overall high quality of the code?
Open-Source users tests parts of the software not tested by the QA team, and vice-versa. Both methods complement each other.
Could automated testing stand on its with sufficient coverage?
No. Some things cannot be tested automatically, especially on the look & feel side.
On a similar note, how do the different methods pursued in customer support (like detailed documentation, peers helping each other, and specialized paid support) interact and draw upon each other?
Documentation is updated based on the most frequent requests from customers. Paid support users are usually different from mailing list users, although some of the latter do convert to the former from time to time. Guillaume I phrased the questions deliberately at length to roughly stake out
the areas I would be more interested in. Every comment, opinion or experience that relates to the given topics is highly welcome. I will eagerly keep track of the mailing list for answers and follow up with the next round of my questions in a few days.
Kind regards, Martin _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Martin, Sorry for having taken so long to answer. We have a lot of holidays in France in May. I flagged your message as important then took some holidays, forgot about it, then other holidays and now I'm back! Disclaimer: I have 2 hats: * one as an xwiki committer like any other * another one as the CTO of XWiki SAS (http://xwiki.com) See below. On Apr 20, 2012, at 8:43 PM, Martin Schönberger wrote:
2012/4/14 Vincent Massol <[email protected]>:
Well I'm fine with both too but I really think you'll get more extensive result from asking on this thread: * you'll get the sum of our knowledge. There isn't a single person who knows it all here. We all have some knowledge of some part of XWiki and we don't always agree! (which is very fine) * this interaction will be archived and searchable in the future so people won't just see the result but the whole interaction and the various answers from different people
So I'm all for doing it here :)
Well, consider me convinced. :) Let's try this the open source way then! Everyone is very welcome to join in on the conversation.
As Vincent suggested I am going to split up my questions into three or four posts, roughly separated by topic. This first post contains rather general questions about the process and the stages of development, while the follow-up posts concentrate more on the project's management, people, structure and infrastructure.
You can assume that I am aware of the development process as far as it is detailed on dev.xwiki.org and xwiki.com, and for my research I would like deepen this knowledge, especially on how the process is applied in practice, and how it is seen from within.
So, without further ado, my first questions:
As far as the process is concerned directly, which are the parts of development that profit most from the fact that XWiki is open source?
Obviously it's hard to contribute to the core of an open source project than it is to contribute to extensions/plugins. This is the case with XWiki. Actually what we've started doing a few years ago and this is still underway is to split the monolithic XWiki code into small modules, each implemented a specific feature (tag, querying, wysiwyg editor, rendering, etc). We have hundreds of such small modules which makes it easier to contribute than before. In addition we've started to make all those modules extensions, i.e. features that can be added/removed from an XWiki runtime. And we now have an Extension Manager in the XWiki runtime to manage all extensions. This means that when someone contributes an extension on extensions.xwiki.org it's directly visible from within everyone's installed XWiki runtime, in exactly the same way as extensions created by the XWiki Dev Team. Thus I believe we'll continue to see more and more contribution in the area of extensions. We have several layers of code contribution: http://dev.xwiki.org/xwiki/bin/view/Community/Contributing#HContributeCode Note: I've updated http://dev.xwiki.org/xwiki/bin/view/Community/Contributing this morning Now more generally the XWiki open source project benefits from: * extensions * testing by the community and bug reporting * discussions on the mailing lists to give ideas, to direct our work
It seems like XWiki has a rather large core team closely working together, and the Hall of Fame lists rather few external contributors. Does this reflect the actual distribution in the project?
The list is valid for the committers. We're about 15 active committers (ie. XWiki Dev Team). We've always had a hard time identifying contributions since there are lots of ways to contribute. Thus we asked contributors to add their names to the Hall of Fame page but lots of people are shy or simply don't think about putting their names there. We've now moved to GitHub and it's much easier to recognize code contributions since we now use pull requests. I'm preparing a new section for the hall of fame that'll list all code contributors (and not only committers).
What are the costs and benefits of using open source development methods in this situation? Would communication patterns, knowledge management and development cycles be approached differently if XWiki was developed purely in-house?
Definitely. One important difference is that there's no power hierarchy in XWiki development. All the committers are equal. We have built our rules on the Apache model which is a Meritocracy. See http://dev.xwiki.org/xwiki/bin/view/Community/Committership and especially our vote strategy. It's enough that a single person doesn't agree for something to not happen.
Another thing I'm interested in is how the scope of the project and the direction of development are decided on. To what degree do different stakeholders influence the course of XWiki, what is caused by personal itches of the developers, requests of paying customers, or complaints and suggestions of casual users? Is there a special time in the release cycle when new content is agreed upon? How far and in what detail can the content of future releases be planned ahead by the developers? Are detailed plans desirable, or is it more advantageous to react to circumstances when they arise?
The strategy: * In the open source project, there are only individuals, no company. At the start of each release committers and contributors can state what they'd like to work on for this release. We publish this on our roadmap page: http://www.xwiki.org/xwiki/bin/view/Main/Roadmap (specialment http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap pour XE). * At XWiki SAS, we do internal roadmap meetings and then find/assign developers who're going to be the owners of issues/features on the xwiki open source project. During these internal meetings we have representants of all XWiki SAS domains (marketing, customer project, sales, tech, research, infrastructure, etc) present and decide in a collegial manner.
The third question concerns specialized tasks surrounding the development. XWiki follows diverse strategies for testing. One of them is manual, formal testing executed by a dedicated QA team.
Actually we don't have any notion of QA team in the xwiki open source project. At the open source level each developer is responsible for the quality of his code and is supposed to write automated tests and do manual testing of his code. However we have one contributor named Sorin Burjan who's helping the developers do this by systematically testing new releases himself. He's helping us a lot. But he's acting as a contributor. Now Sorin is also an employee of XWiki SAS and within XWiki SAS his role is QA engineer and his internal role is to make sure that releases are of good quality.
Does this part of the approach make the many-eyeballs-method of discovering bugs less important, or is a combination of these two strategies necessary for overall high quality of the code?
Combination. I'd say the vast majority of issues are still reported by the many eyeballs. But Sorin finds a good lot too! :) Both are needed.
Could automated testing stand on its with sufficient coverage?
IMO it could but we haven't reached a good enough level yet. We need to become better at this and start measuring better our test coverage. We have just started automating tests on various environments (DBs, browsers) and that'll take some time. In the meantime Sorin has taken charge of manually testing XWiki on those various environments. At some point we'll also need to add automated performance tests which is done manually too at this point.
On a similar note, how do the different methods pursued in customer support (like detailed documentation, peers helping each other, and specialized paid support) interact and draw upon each other?
XWiki SAS internal support will raise issues in our issue tracker like anyone else and these will get fixed eventually. In general the most people who report an issue and faster the XWiki Dev Team spends time on fixing it quickly.
I phrased the questions deliberately at length to roughly stake out the areas I would be more interested in. Every comment, opinion or experience that relates to the given topics is highly welcome. I will eagerly keep track of the mailing list for answers and follow up with the next round of my questions in a few days.
Thanks, hope it helps -Vincent
participants (5)
-
Ecaterina Moraru (Valica) -
Guillaume Lerouge -
Martin Schönberger -
Sorin Burjan -
Vincent Massol