> >> 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. 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 ;) > 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) 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. > 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. > 3. These are volunteer efforts. If you're not paying someone, you can't > expect to direct their approach too much. Volunteers who are spending > too much time doing things they don't want to do tend to quit. I volunteered to quite a few free software, and I never spent time doing things I didn't want to do. And I certainly don't expect anyone doing something for me for free if they don't want to do it. This being said, they are plenty of free software that are successful, including donor management softwares. >> 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 ;) >> That's the Academic Free License. The AFL gives them the right to >> relicense the code in the future _and_ to create proprietary >> derivatives, >> from my reading. >> >> Of course, the sane way to do this is to simply ask contributors to >> assign >> copyrights to you when the contribute. Another approach is a CLA (you keep the copyright, but give the organisation some rights so they can decide for instance to re-licence under GPLv3). ...or go for a BSD licence, or... plenty of options ;) > Sigh, this disappoints me. I don't like non-straightforward things. I > presume they're not asking contributors to sign the code over to them > because many people would balk at assigning copyright to a for-profit > company. So instead, they found this roundabout way of getting the same > rights without contributors realizing it. I have a hard time respecting > CiviCRM with stuff like this going on. FYI, CiviCRM is a not for profit, and unless I misread something, you can write a contribution under the AGPL, and if they want to integrate it into the core, they will have to convince you going AFL, or, hopefully, choosing an easier licensing system. Anyway I don't like it either, and that's too complicated. It'd be great if this discussion can help them choosing something better! Xavier _______________________________________________ software mailing list [EMAIL PROTECTED] http://lists.flossfoundations.org/mailman/listinfo/foundations-software
