On Fri, Jul 24, 2009 at 1:55 AM, Minh Nguyen<nguyenmi...@gmail.com> wrote: > > Hi folks, > > I just come across a document outlining some barriers to growing a > community around an open source project. You can get it at this blog > post: > > http://blogs.gnome.org/bolsh/2009/07/22/barriers-to-community-growth/
**Vision and product** Mission Statement is clearly defined and helps people know what we are doing, and usually very easily answers the question, "should Sage do X?". It is: "Create a viable free open source alternative to Maple, Magma, Matlab, and Mathematica." Sage is different than many other math software projects in that (1) we use a mainstream language (Python) and (2) we put much effort into building technical and social relationships with other projects and research groups. Also, the Sage project is perhaps more ambitious than many other projects. ** Install issues ** * Is your software packaged for popular distributions? We fail here mainly in not having a native windows version. * Does the make install target work well? Yes * Do you use system versions of dependencies when available? Famously no. But I believe we make the right choice here, because of the extreme level of rigor and correctness requires for mathematics, and the rapid improvement (=general instability) of the components of Sage. * Is the configuration of the package more complicated than it needs to be? No, you just type "make". Sage is amazingly trivial to configure. * Is there a good README and INSTALL on getting started, and a “Getting started” page on your website? Yes, definitely. Plus quick help on sage-support. * Is there an easy migration path for data from one version to another? Yes. In theory, all data automatically migrates and "just works". (Of course there are some problems in practice, e.g., with recent symbolic differentiation code.) ** Build issues ** * Do you use uncommon build tools or development tools? Nope. We make building easy. * Does the software have a large number of dependencies? NOPE! They write "Software with a large number of dependencies may be good architecturally, re-using code wherever possible. But it makes building the software more complicated, sometimes requiring a new developer to struggle with different toolchains, build procedures and packaging issues." I think we do very good on this point. * Do you require dependencies which are not commonly available in a typical Linux distribution? Nope! They say "Worst of all is depending on software which is not commonly available, and which depends on another uncommonly available package. A developer can spend hours chasing down rabbit holes looking for the correct versions of required packages." During at least the first 2 years of Sage, this would have been half of the dependencies of Sage, and would have taken weeks, not hours, for a typical developer to sort out. * Do you require dependencies whose API changes frequently, making it difficult for the user to know if they have the right version? Nope! * Do you develop in an uncommon programming language, requiring learning a new language and the installation of a large number of packages? Nope! They list the common "good" languages as "C, C++, C#, Java, Python, Perl and Ruby", so we're good with our main languages being Python + C. * Is the source code easy to find and easy to download on the website? Definitely. * Does the software take a long time to build? Depends what "long time" means. They write " Does the software take a long time to build? They write "OpenOffice.org famously takes over a day to build on a powerful development workstation. Recompiling a one-line change can take hours. Correcting build failures and setting up the initial build environment can take a skilled engineer a week or more. This barrier to entry is far too high." Given what Sage gives you, and that one can immediately develop with binaries, I would say we even do fine by this metric. I had no idea building OpenOffice from source is that much harder than Sage. ** Product architecture issues ** * Is there a good architecture overview document? No, not good enough. I did give a series of 4 talks 2 months ago that were an architectural overview, and should turn them into documentation... * Have you identified the three or four most likely changes a developer will need to make, and tailored developer guides for those tasks? No, that would be a good idea for a tutorial. What are they? * add a new function to some existing class * improve plotting in some way * fix/improve something in the GUI notebook server * add a new ring/field/element * Is there a community documentation repository? Is it maintained and accurate? Yes, yes for the most part. He says " I suggest recruiting members of the community who are passionate about this kind of resource to get involved as official “wiki editors”, in the same style as wikipedia. Daily pruning prevents wild outgrowth of wikis. " * Does your product have a modular architecture that allows newcomers to make small contributions without understanding how everything works? Yes, definitely. Thanks Python and that Sage is built out of a hundred components. * Are proposed contributions evaluated quickly? He writes "When proposed patches are received, are they reviewed in a timely manner, or can they stay unreviewed in your issue tracker for weeks or months? Do you track average and longest unreviewed patch time regularly? This is a key metric for community satisfaction." I think our patch review process is too slow since indeed things do stay unreviewed for weeks (and sometimes months). We must find ways to do better here. So far, Tom Boothby has been by far the most successful at setting an example of how to improve this critical aspect of Sage development, IMHO. ** Project infrastructure ** * Do you have a developer mailing list? Yes. * Do you have a users forum? Yes * Do you have bug tracking software? Yes * Do you have a wiki? Yes * Do you provide a platform for community contributions? Yes, at least through interact on the wiki's. Maybe we should do better though, and make it easier for people to post official nontrivial contributions that haven't been refereed.... I don't know. * Do you have a real-time communication channel? Yes. The document amusingly says: "There is a down-side to IRC which should be kept in mind. Over time, the people who will be most active in IRC will tend to be people whose only contribution to your project is being active in IRC. This is not necessarily a good thing. Bear this in mind later, when we talk about the “No asshole rule”. " * Do prominent community members blog? Is there an aggregation of their blogs? Yes. ** Behavioral norms ** * Have you documented accepted behavioral norms? Does your project have a community Code of Conduct? No. Should we? What would it say? * Do you enforce a “No asshole rule”? The document says: "The cost of not enforcing a rule of no deliberate rudeness, no ad hominem attacks, and making sure that in general people remain civil is that uncivil behavior will become the norm for your forums." I think we do a good job of avoiding rudeness, especially during the last few months we have been doing better and better. The forums are I think very civil and when people are offended, they feel comfortable saying so, and there is always a quick apology. * Are employees and community members held to the same behavioral standards? Yes, though maybe this wasn't always the case for us. ** Governance & transparency ** * Are all of the project's decision makers on the developer mailing list? Yes. They go on to say "In many corporate projects, the most damaging dynamic is when a decision gets made by someone not on the developer mailing list, and is thus completely unaccountable to the community for the decision. It is damaging for your community, who feels ignored." As much as possible, all Sage decisions are made "on list". * Has your community/corporate governance structure been clearly documented? They write "Many forms of technical governance are possible. A dictatorship with a “benevolent dictator for life” is one popular system, rule by committee is another, and all too often anarchy is the system which bubbles up, usually after an initial project founder moves on to other things. The important thing is to document your governance structure." Our governance structure is decision making by very public developer voting whenever possible, and BDFL (me) in those cases when decisions just need to be made. I try to take this responsibility very seriously. * Is there a clear path for external contributors to become core committers? Yes. Implement it and post a patch. (This is mainly a "company question"). * Are all your developers active on the mailing list? Yes. * Do you get key contributors together regularly? Yes!! (Sage Days) * Do new employees get the keys to the house on their first day? Not applicable. * Does the community participate in product roadmap discussions? Yes. This was a recent change with the creation of the sage-release mailing list. * Are all decisions made in public? Yes, as much as possible. * Are you managing confidentiality? Not applicable ** Legal barriers ** * Do you have a JCA? NO. They write "Joint copyright assignment is often required from external contributors in corporate driven Open Source projects. This is not a fatal barrier to entry, but it will certainly dissuade some developers. " * Do you have an “always Free” commitment? Yes. * Do you have a trademark policy? No. They write "Many projects have had trouble reconciling copyright and trademark law. The most prominent case is Mozilla Firefox and Debian Iceweasel. A well defined trademark policy, outlining what you consider acceptable use of your trademarks in community usage of artwork and derived versions of the software, will go a long way to alleviating these issues. " Obviously the above should be on our todo list. Is anybody reading this interested in doing something about this? A starter would be to trademark "sagemath" or "SageMath" and maybe a logo, and come up with a policy statement. This is not of personal interest to me yet, and it hasn't happened yet, but I strongly encourage somebody to do it! * Do you have a GPL policy for externally developed modules? They write "Do you have a policy in place concerning what is covered by the GPL, and what is not?" We can't do anything like that because we don't own enough of the copyright of the components of Sage. -- William --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
