<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Every non-profit has a different workflow, and the problem is the</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">existing systems are built around specific sub-area workflows (OA for</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Arts orgs, CiviCRM for campaigns/canvasing).<span class="Apple-converted-space"> </span>We need a more modular set</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">of stuff that can model different workflows.</div></blockquote><div><br></div><div>I would say that both OffstageArts and CiviCRM are modular. Both offer a number of modules that provide specific functionality for certain kinds of tasks. And both are free software, which allows people to write additional modules to them. I will do everything I can to support the efforts of people who wish to add modules to OffstageArts.</div><div><br></div><div>The reason (at this point) that we don't have one system that's suitable for everything is because the existing systems don't have modules that cover all functionality. Everyone has basic CRM functionality. But beyond that, it varies: CiviCRM can do bulk email and event management. OffstageArts can print mailing labels and run a school. In both cases, the specific set of modules included has most likely depended on the needs of the early adopters. And in both cases, many more modules are planned. Planned modules are vaporware, of course --- but I hope we ARE thinking long-term here, rather than looking for one system off-the-shelf that can serve everyone's needs without any extension work --- because there will never be such a system. Therefore, we need to evaluate products in terms of their core design and their flexibility --- their ability to be extended by programmers and consultants, at low cost, to suit a variety of needs. And we also need to evaluate the ability for customizations and additional modules to be integrated back into the core codebase for everyone to use.</div><div><br></div><div>Another reason for the perceived lack of universality comes down to practical business and marketing reasons. OffstageArts, for example, has been developed so far on a very limited budget. Considering the state of the market and the resources I had available, I believed my best chances of success were to be had if I pursued the niche market of arts organizations -- this was a market niche with NO effective existing products, free or non-free. Of course I understand that OffstageArts can work for non-arts non-profits, and I've even already deployed it for some such organizations. But the marketing is still (for now) arts specific, since that is where I have the best networks and there is the least competition.</div><div><br></div><div><div>I disagree with the assertion that there is no existing system that fits the needs of this product; rather, there is already more than one. The only thing sitting between us and a complete system that can service every organization's needs is a <b>sustained, common investment in one system,</b> to add modules as needed. And the maintainers of code need to be committed to integrating modules of all different purposes, not just the purposes that they understand. There is no need to re-implement the basic functionality in already-existing systems, since it is possible to extend and add features to existing systems.</div><div><br></div><div>I would love to see modules added to OffstageArts that serve needs not common in the arts sector. For example, with a little bit of thought and an additional module, OffstageArts would be suitable for the management of most American churches. Even the name of the product can be changed, in order to better suit additional niche markets. That would open up an entire new effort, and it would require a sustained marketing push in terms of signing up and training the thousands of churches in this country. To make this work, we would need consultants who are networked in the church world and interested in pursuing this kind of consulting work.</div><div><br></div></div><div>In addition to wholesale new modules, a lot can be achieved with already-existing customizations. Both CiviCRM and OA are also already customizable, as any system needs to be if it can enjoy widespread use. OA allows customizations in fields, tabs, price computation, reports --- and probably more in the future. CiviCRM similarly offers a high degree of customization. Just the addition of fields and tabs provides an astonishing degree of capabilities for various organizations, since it allows them to add space to record structured data that is unique to them. For example, one organization specializes in giving tours. Although I'd never designed "tour management" capability into OffstageArts, we found that a couple of customized tabs were able to serve their needs. Total time to build these tabs: under 1 hour for maybe 30-50 lines of code per tab. Customized reports then allow those data to be used in novel ways. A lot of thought has going into OffstageArts to allow customizations and the main code base to work together seamlessly.</div><div><br></div><div><div>Finally, it is important to consider this kind of software not just in terms of how we will build the capital infrastructure (the code), but also how we will service it. Non-profits will not just use a system because it's available on SourceForge and has no license fees. Rather, they will use it because a consultant tells them it will solve their problems. </div><div><br></div><div>And even though we know that one common software platform can service a wide variety of organizations, consultants do not usually operate that way. Consulting organizations tend to build networks in specific industries, and become experts at talking the language, understanding the needs and providing solutions for those industries. Therefore, in order for a common platform to be used in a wide variety of market niches, we need to:</div><div> 1) Identify each niche.</div><div> 2) Make sure that our product really answers the needs of that niche, extending it if possible.</div><div> 3) Network within that niche to develop the contacts needed to see the system adopted.</div><div><br></div><div>There is a lot of on-the-ground work to be done beyond building the code base.</div><div><br></div><div><div>In trying to find a "one system" that can serve needs, maybe we should be talking about building a common shared database schema that can be extensible and can support a variety of needs in the future. I believe that FSF has considered this at least once in the past. Not only would this help standardize the development of existing products --- it would also ease integration between products as needed, without having to re-implement features from one system into another. Rather than porting CiviCRM's email capabilities, I could (for example) just use them with OffstageArts by pointing the two to the same database.</div><div><br></div><div>If there were common momentum to a shared schema, then I would definitely want to migrate OffstageArts to it. This is like the standardization on OpenDocument format and the subsequent adoption of the format by a variety of word processors and automatic text processing tools.</div><div><br></div></div></div><div>-- Bob</div><div><br></div></div></body></html>