GSoC 2013 Scribus Team Application
The Scribus Team includes the core development group and the translation, testing, and user support contributors located on every continent who cooperate to develop Scribus - a cross-platform Open Source Desktop Publishing Software. Scribus is now a 12 year old project, which began as a Linux-only program, but now offers versions for Windows, MacOSX, and even less-commonly used environments like OS/2. Scribus provides professional publishing features, such as color separations, ICC color management, versatile PDF creation, and pre-flight verification, as well as a Python scripting engine. In the Linux/UNIX and OS/2 worlds, Scribus is the only professional-grade Open Source Desktop Publishing Software, and on Win32 and Mac OS X, Scribus is used by an ever increasing number of professionals, as well as demanding amateur users. One can get some idea of the quality of PDFs made with Scribus, as well as the breadth of use by checking some of our Scribus Success Stories: http://wiki.scribus.net/canvas/Success_stories. The project has been recognized by a number of outside organizations and publications in trade and popular literature. For instance, Scribus was March 2012 Sourceforge.net project of the month.
Organization home page url
Main organization license
If you chose "veteran" in the dropdown above, please summarize your involvement and the successes and challenges of your participation. Please also list your pass/fail rate for each year.
We participated in GSoC 2007, 2008, 2009, 2011, and 2012. Both our GSoC 2007 participants successfully added math formula editing support via LaTeX frames and an imposition plugin. All three GSoC 2008 students were successful. They developed a new generation Python scripter, versatile vector and bitmap import via UniConvertor and GraphicsMagick, and a well-polished picture browser. GSoC 2009 work added PDF/X-1a and PDF/X-4 export and improved the PDF embedding functionality, although only one project out of four was successfully completed. We did not participate in GSoC 2010. GSoC 2011 was a complete success as an outstanding GSoC student performed a long overdue rewrite of the table functionality and the other student completed the scripter2 API and the transition from scripter1 to scripter2. During GSoC 2012 we had two successful projects out of four - one focused on a set of usability improvements most requested by our community and the other focused on the development of a next generation XML format for the Scribus documents.
A measure of our GSoC success is the fact that two of our GSoC students joined our team and another one became a contributor. In 2007 we learned a lot about selecting students, managing mentor-student communications and expectations, and finding problems before they turned into major obstacles. This allowed us to streamline the GSoC 2008 selection and mentoring processes and achieve a 100% success rate in our second year. In 2009, our efficient process organization allowed us to quickly identify the disparity between students capabilities presented during the selection process and their actual abilities to communicate and produce results once the projects started. We quickly culled projects with no hope of successful completion and prevented waste of GSoC funds whereas the student who was open to communication and problem resolution received all the help needed for successful completion of their project. In 2011, we encountered our best GSoC participant.
Our challenges throughout those four years of participation were consistently related to the students' communication difficulties and students lack of planning and appreciation for the complexity of the GSoC projects. In one case, time was lost due to a student's withdrawal when confronted with coding problems. In another case, two students had problems connecting with their mentors on IRC due to the time-zone differences and network access difficulties, but they were able to switch to email and to use it in a productive manner in conjunction with the use of subversion branches. Fortunately, we had a supporting infrastructure that helped continue the flow of code and reviews. In 2009, two of our students did not make us aware of their school commitments that effectively made them drop out of GSoC as they were not able to commit sufficient resources to their projects. A third student had to cancel his GSoC participation due to a serious family-related issue. We had to manage one of the GSoC 2011 projects more carefully to make sure goals were met, but did not encounter any big problems. In 2012 two of our students did not complete their projects due to personal issues and the disparities between project difficulty and skill sets.
For GSoC 2013, we plan to focus on a very reasonable set of much needed Scribus improvements, which are well within the ability of a capable student to complete and plan to go with a single project and multiple capable and active backup mentors.
If you chose "new" in the dropdown above, have you applied in the past? If so, for what year(s)?
Why is your organization applying to participate in Google Summer of Code 2013? What do you hope to gain by participating?
Desktop Publishing is a complex process that requires a well-designed workflow with layout software as its crucial component. This complexity is reflected in the commercial market dominated by two software companies with no interest in platforms other than Microsoft Windows and Mac OS X that are often not responsive to customer input especially for enthusiast/amateur market. Without Scribus there would be no Open Source desktop layout on alternative platforms, and the ability of people in the developing world and users of Free Software to produce professional level documents would not exist. Scribus has come a long way from its humble beginnings to rival many aspects of the commercial products with large budgets and professional developmental teams and sometimes overtake them in new features and capabilities. However, because our core team is small the development of Scribus is by necessity directed into the areas with the highest return for our users as reflected in the roadmap - http://bugs.scribus.net/roadmap_page.php - but many possible small development areas are currently stagnating due to the lack of manpower. We are hoping to focus our GSoC 2013 efforts on a single student by providing a well-defined set of issues to work on and an enthusiastic primary mentor backed up by a number of secondary mentors to help guide and support the student. Our preferred outcome would be to find and retain a new developer for our team.
What is the URL for your Ideas page?
What is the main development mailing list for your organization?
http://lists.scribus.net/mailman/listinfo/scribus-dev is the developmental discussion list.
What is the main IRC channel for your organization?
- scribus on FreeNode. We also use #scribus-dev for more specific development-related discussions.
What criteria did you use to select your mentors for this year's program? Please be as specific as possible.
Our single primary mentor this year is an enthusiastic new developer who has shown a terrific drive to improve Scribus, an excellent grasp of the code and the developmental process, and the ability to function well in a team. Moreover, there are several backup mentors with many years of Scribus coding experience and deep knowledge of various Scribus subsystems who are willing and capable of helping a GSoC participant have a fruitful and fun Summer of Code.
What is your plan for dealing with disappearing students?
We would like to be very focused this year and work on finding a single student who shows both the potential to get the project done, and a desire to become a long-term contributor or a core developer. To achieve this goal we plan to only proceed with a project if a prospective student establishes good rapport with the mentoring team, is a good communicator, and is technically capable of completing the project. Throughout the project we will have several mentors in contact with the student via multiple channels of communication as necessary to make sure any issues get resolved expeditiously and the student does not become frustrated or uncommunicative. If possible we will arrange for a personal meeting or meetings of one or more mentors with the student to establish an environment conducive to the continued involvement of the student with our project after the GSoC.
What is your plan for dealing with disappearing mentors?
We never had disappearing mentors. Responsible and co-operative behavior is one of the strengths we see in our project. Certainly, one of the backup mentors or the primary mentor might become ill or need to step away from the project due to personal matters. However, we do not anticipate any problems with another mentor stepping in to take over as we are going for a highly-redundant mentoring team this year. In addition, open monitoring of the student's progress via our public mailing list and IRC channel and git commits will allow the rest of our team to keep abreast of the GSoC progression. We do realize that the assigned mentor is primarily responsible for ensuring continued student compliance with their GSoC contract.
What steps will you take to encourage students to interact with your project's community before, during and after the program?
We intend to work hard to select a student who shows that they are willing and able to communicate and work with our team and with the Scribus Community. We conduct much of our development discussions on IRC and ask students to be present there as much as possible. Over the years we have found that the open and friendly atmosphere characteristic of our mailing list and IRC channels has helped a number of people make a transition from Scribus users to contributors and to team members. We believe that by exposing students to this friendly and encouraging environment we can foster their sense of involvement and help them see how their accomplishments help the entire community as much as being rewarding learning experiences for themselves. The absence of interpersonal conflicts on our mailing lists and in IRC channels given the large number of community members with diverse viewpoints shows that this strategy has been productive.
What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes?
We believe that the enthusiasm of the primary mentor and the core team for the Scribus Development, the dynamic, friendly, and supportive atmosphere in the Scribus Community, and the fascinating world of the Desktop Publishing will draw the student back to our project after the GSoC concludes. We also think that the involvement of multiple backup mentors will help the student quickly traverse any learning curves and start enjoying the Scribus Development as much as possible, which could be important for their decision to join the project afterwards.
We realize that in some respects, DTP is a niche type of software. What we see from users unfamiliar with the existence of DTP software is often great surprise that Scribus exists, and continuing surprise about what it can do. What we can hope for is that our student will have the same surprise and decide to stay with the team once they become familiar with interesting issues still needing to be addressed. What we will continue to do is what we've always done - try to be helpful to users and potential team members, offering what assistance we can to help them find their place in the Scribus community. As noted, we have already had some success in attracting students to stay on after GSoC.
Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here.
Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here.