On Tue, 2008-10-28 at 16:30 +0100, xavier dutoit wrote: > > > >> Since my first goal is to write something for my animal rights group that > >> I can maintain easily, I'm really only interested in doing it "my way" for > >> now. > > > > I think this is a good approach in general, for several reasons: > > I don't think that's a good approach in general, for several reasons ;) > > The main one is that, as that's been proven over and over by plenty of > free softwares, you can actually have a lot of > organisation/individuals having roughly the same needs that can be > addressed the same way. I like having competition between different > softwares that try addressing more or less the same need, but only > when they have different philosophical/usability/goal/technological or > whatever meta objectives and focus, but IMO that's lost energy to do > it because of the "not invented here" syndrome, and people liking to > reinvent the wheel for the sake of it.
I've thought a lot about this. Effort is wasted when work is duplicated. OTOH, innovation can wane when there is only one way / one product. There's no need to write your own web browser today; there are already zillions, and browsers are well understood. But we're in a different space with NPO software. For many nonprofits, we don't yet have even ONE product that fulfills their needs. One problem in the NPO space is that "more or less the same need" is a far cry of "fulfills 100% of the needs of an NPO." This is a different space from the mass market software we're more familiar with. It's easy to build a piece of software that fulfills 90% of the needs of 90% of NPOs. Whether that can translate into fulfilling 100% of the needs of x % of of NPOs (for any x>0) is an open question. Every NPO is different, and has different needs. And we cannot ignore installation/customization/training costs of a piece of software, since they can present a significant barrier to use for most NPOs. We know that Rapport2 and OA both fulfill the needs of at least one organization --- and that a decision was made to undertake a sizable development task rather than use off-the-shelf software. I can't speak for Dave, but this was certainly not a task I undertook lightly. And we also know that CiviCRM fulfills needs of some organizations. > You're obviously free to do whatever you want, but it might be more > productive to benefit from dozen other contributors, even if it means > having to learn "their way". Who knows, their way might even not be > too stupid ;) Over time, products have a way of attracting these communities in a natural way. I don't think we need to rush the process at this point by "picking winners." We're way too early in the process, IMHO. There are zillions of examples of "competing" products in the free software space. PostgreSQL vs. MySQL is one. The two have different guiding philosophies: PostgreSQL aims to implement innovative (read: sometimes experimental) features. MySQL aims to implement only features that have a well-tested mindshare in the database community. MySQL has mass market appeal because they've done a good job at implementing existing practices well; PostgreSQL has the GIS market to itself because its extensibility allowed it to support GIS-specific features that would not be appropriate to integrate into MySQL. Two or more similar products can certainly get along. Free software should be more than a simple rote application of existing design principles. Too often, free software is simply playing catch-up to existing proprietary solutions, maybe improving on them here or there. NPO software is one space where we can leap far ahead. But to do so, we have to be willing to try multiple different approaches in the design, architecture and deployment models. OffstageArts embodies a number of new software engineering ideas. If these ideas are successful, then it will be known that they were developed in the free software community (as the proprietary folks play catch-up). It is interesting to point out that PostgreSQL is well-suited for GIS in ways that most (all?) major proprietary databases are not. It is out in front. > > 1. Each project came to this group with particular processes and goals > > in mind. Participation should not undermine these processes and goals. > > However, if the software is > 1) well thought enough, > 2) Customisable easily > It should be possible to use a "generic" tool and twist it so it does > it your way (and who knows, you might even improve your process by > discovering other way of doing what you do) It's not possible to change fundamental architectural decisions of a product when customizing it. Examples include language, client/server architecture, extensibility architectures, and (as we were discussing) the use or not of stored procedures. > Have you tried some of the software discussed on that list ? I'd love > to know what was missing in them based on your analysis. Yes, I have. * CiviCRM: I did a long write-up on it. It has many great features. Does not do some things that arts organizations need. Also... when I started OA almost 4 years ago, CiviCRM was a much less mature product and less of an option than it is today. * OffstageArts: I'm aware of its many shortcomings. Used by some NPOs, but still a work in progress. Its deployment model could end up being too high-end for many non-profits. It's an open question whether or not it will be the kind of software that can be casually used by NPOs without at least a few hundred dollars spent on a consultant. However, it has a good chance of taking over the high-end arts database market, and of reducing prices from $5K/mo to more like $100/mo. * Rapport2: I've not had the opportunity to try it, but Dave has discussed many promising features of this system. I believe it is likely to become a preferred solution for a large number of small-and-simple nonprofits whose needs are similar to the animal rights organization for which it's currently being developed. It could become the low-cost solution for these kinds of NPOs, and a serious competitor for Raisers Edge and eTapestry. I'm sure that when Rapport2 gets to a certain point, we'll all be able to try it out with an on-line demo. * Grace: Looks like it's still in the early stages of development. No docs, no screenshots. Could turn into something, we'll see. In the meantime, I don't have time to compile it myself. * On NGO: No source code, no demos, no docs --- nothing but a 1-paragraph plan to build a system. * project-open, Compier, ERP5, OpenTaps: These seemed to be targeting a different market. I'm not sure how inventory management relates to most NPO needs. Sometimes, issues other than the finished product motivate people to build free software. There has certainly been some of that with OffstageArts. > > > 2. There are many ways to skin a cat. Each project has a vision of how > > it's doing things and how the parts will fit together to form a whole. > > If that vision is allowed to continue to the end, then it has the best > > chance of producing a coherent piece of software. If it's constantly > > interrupted, the software can become "design by committee." > > Absolutely, and some OSS have become bloatwares precisely because they > lost their focus, offering a zillion half backed features and > servicing none of them very well. However, some are able to offer a > coherent tool, that allows to add hooks and customisation on the side > without having too many things in the kernel. > > I suppose that the fast majority of the softwares you use on your > computers aren't written by you. Doesn't make them less useful to do > what you want, it could apply as well for the software managing your > organisation. I don't think you understand my point here. We were discussing technical details of software --- what client/server architecture you use, what language it's written in, whether it uses stored procs, etc. I don't think it's very helpful to have people from outside a project come in and say "you should use language X, design principle Y, database Z, etc." Advice is always welcome of course, but in the end these decisions should be made by the project architects. If they are good decisions, then the software will be good --- and other projects might make similar decisions in the future. If not, the project might die out over time. We are right now looking at different products with radically different architectures. It's unlikely that a programmer working on one of the projects will have the skills to work effectively on another without significant retraining (which is a lot of ask for volunteers). I would certainly not retrain to work on a Perl or PHP project. Nothing personal against Perl or PHP, but I am in the middle of developing new software engineering ideas in Java. I have pushed the state of the art far forward in Java, and now have a rather unique skill set. I need to keep working on and communicating those ideas. Economically, it makes sense to work in an area in which you skills have the greatest relative advantage. > This > being said, they are plenty of free software that are successful, > including donor management softwares. If that were really true, the FSF would not have been soliciting NPO software proposals as a high-priority project. NPO software is a tough space to work in. It would be disingenuous to tell the world you badly need NPO software, invite the world to come to you with said software, and then tell the people who come forth with actual software that they should stop working on it and instead work on some other project you think would be a better use of their time. > >> Personally, I think a REST API has greater potential than stored > >> procedures, especially for a hosted service, for obvious reasons. > > > > This is an example of what I mean. Stored procedures may be more > > appropriate for some systems that use a different architecture than the > > ones we're looking at now. Apparently, the REST API can serve similar > > purposes. (I'd never heard of REST, it looks like I have some reading > > to do). > > That's both an interesting architecture and the buzzword of the week, > stretched to cover almost every api accessible via TCP ;) OK. We will see. It's at least worth reading the dissertation that invented REST, and trying to understand how that relates to the architecture Dave has described for Rapport2. Again, thank you for pursuing the licensing issues with CiviCRM. Sincerely, --- Bob _______________________________________________ software mailing list [EMAIL PROTECTED] http://lists.flossfoundations.org/mailman/listinfo/foundations-software
