Sustainable CiviCRM Part 1: A service provider association

Thanks for outlining this, Michael.  One thought I had was whether this would be an actual association (though as simple an association as could be established) or simply a "preferred partner" sort of program where companies pay to get listed and nothing more.  There are advantages and disadvantages to each--both from the perspective of a CiviCRM provider and from CiviCRM itself.

An actual association would need an actual board with actual control over the dues.  This would mean at least a certain amount of paperwork to file on setup and on an annual basis--and the potential for a new bureaucracy.  For better or worse, it would also mean a literal entity with full control over a portion of CiviCRM core team revenue: that includes the ability to direct it towards certain features, other non-core-team developers, or even execute a Joomla-like fork of the project.  On the other hand, many of these powers exist de facto already: we could all just quit, put our money elsewhere, or do what we want ourselves with our own payrolls.

A "preferred partner" sort of situation has different concerns.  Firms could lose faith in what the core team was doing, slowly dropping out as they feel they can't redirect the ship.  Prospective clients might see the "preferred partner" program as simply a way to feature companies with cash to throw around, ignoring them and going with some random web developer who tells them, "Oh, I've heard of a Drupal module that'll do all your CRM work for you."  Meanwhile, the structure would concentrate control to be at the core team--though this is effectively the case already, association dues could become an empty commitment in lieu of committing time and creativity to the project.

I don't have extremely strong feelings toward one method or the other, but I do think that it's a factor to consider in these early conversations.

My initial thoughts:

• In general I think this is an excellent idea and very appropriate
• I would like to be part of the implementation
• I think it should not be an association, but a partner program 
• I think pricing by full time FTE's is appropriate, but hard to police.  I think the # of FTE and $$ paid should be public to discourage organizations under estimating.  Contractors should be included in th FTE numbers.
• There should be some benefit to organizations that contribute a lot besides $$; not sure how to compensate though
• There should be some base criteria to join and stay in the program besides $$
• How will people searching for "experts" be able to decide which is better, an active contributor or an association member; should we have the distinction, if so, maybe it could be more of an attribute then a completly different list of organizations. 

This is a very welcome and appropriate initiative.

I'm okay with Partner Program as well as Association. I think being a CiviCRM Partner is more understandable to potential clients than Association Member. But if there is going to be $50k - $100k involved in the first year, and a small group of representatives, then it is worth incorporating as a non-profit. I've created several over the years, including the Toronto Drupal Users Group, and it is neither difficult nor expensive.

I also think that a properly constituted non-profit would be a good locus for one type of voices in project governance as that evolves going forward, and getting the governance right is appropriate.

I think listing an organization's contributions to the project could include a sum of the staff's contributions in terms of various objective metrics: extensions published, number of core and extension commits, number of lines of contributed code, number of jira issues reported, number of forum posts, forum karma, number of wiki edits, booki metrics if they exist for book contributions, etc. Also, attendance at various CiviCon's could be listed, links to presentations, formal responsibilities in the community eg i18n lead, SF Meetup Lead, etc. There are likely other metrics that are objective and could be gathered reasonably easily. People and orgs should also have space to describe themselves subjectively. drupal.org provides something along these lines for individual users.

I like the idea of pricing by FTE, and using transparency to better achieve compliance. Listing staff and their contributions as per previous paragraph seems reasonable. 

As an integrator, I think it is fair to contribute back to the project, which sustains part of my livelihood. Since the code is available to me anyway, being open source, the only reason for me to support CiviCRM is a mix of gratitude, respect, giving back to the community and ensuring my business continuity is assured.

I think every OS project requires a core team. I also think every OS project requires a permanent pool of resources, funded by the community. I think there needs to be a certain amount of 'benevolent dictatorship', justified by the expertise, performance, effort, contribution and leadership skills on the part of the benevolent dictators. So yes, putting money in the pot makes sense. Having a core team spend that money on what they see fit is OK as well.

That said, and slightly swimming against the stream, FTE-based does not strike me as the best metric. Who is going to determine what FTE I put in ? Wouldn't I be tempted to reverse engineer the amount I want to contribute into an FTE number ? I could argue that 100$ per client we sign up would be as good, or 1-3% of my business revenue based on CiviCRM ...

How do you value people's contribution in kind -- manhours spent, forum activity, ... as soon as money comes into play, and it gets you some advantage (even in marketing terms), valueing non-financial contributions becomes an issue. From my point of view, separating the two feels better : integrators contribute because they care, can and want to. I don't expect a badge or banner in return -- it's the right thing to do.

You can argue that not everyone feels that way. Sad, but true. But I don't think another scheme wil motivate them more. If you disagree, here's the place to say so.

Is is needed and I'd want to help setting that up

Few points to consider:

1) Who controls how the money is used? IMO and especially if its' an association, it'd make sense to benefit from this to vote on the priorities with the money (obviously within the goals and between the tasks you have described) and help the core shaping the priorities.

2) partner sounds better and more official than member indeed

3) I think we should take that opportunity to "certify" the level of knowledge too. eg the partners have to send their staff to training, or attend to meetup/conference, or... 

as in, giving money isn't enought to be "certified partner"

rationale, we should use this as a aim to make the ecosystem more sustainable, this means both a steady financial flow for the core and knowledgable and trustable partners

4) Quantify the non financial contrib is tricky. The risk is that paying will justify less contribution. That's a known effect: if you fine the parents when they are late picking up their kids, more of them will come late, as the financial transaction allows them to buy out their guilt/responsability. 

5) "security" as a benefit

I think the partners should get a early warning when a security bug is identified and a more detailed info, unless the exploit is already live.

On some security issues I've found and reported/fixed, I would have liked to inform "partners" without making it completely public before the fix was released, and I would have liked to be informed before it was public for some of the other issues I wasn't involved discovering/fixing.

The members of this association are, by definition, trustable and would be the right channel to fix faster these security issues.

6) hosting providers

some of the partners might not have lots of full time civi people, but have deep interest and a source of income linked to civi through the hosting. If a partner provides civi hosting, it should be a different price, on the top/instead of the "per worker" price

X+

A more formalized relationship between provider and LLC (what I call 'core team') could be a good thing. Almost all open source projects need money, that's understandable, and this one is run by LLC/core team, so that's settled.  

Let's restate plainly the nature of things as they are.   LLC gives out free software and providers already offer LLC a significant service in return that LLC doesn't have time to provide itself.  Consultants guide dozens, perhaps hundreds, of clients yearly on how to use software they could usually never understand on their own while enlarging the community and building "good rep" for CiviCRM as functional software.  For that service we are compensated by our clients, not LLC, but LLC does benefit too.  Most providers contribute in one or more additional ways as well (patches, testing, volunteering, donations, etc), and I'm not adverse to giving a little more for a logo I can stick on my website, I guess. I haven't updated it in years, maybe this will give me an excuse. ;-)

But let's get down to business.  First, I think the proposed association benefits listed (discounts, logos, etc) are uninspiring, even for a provider actively seeking new business, except for the last one: "sustainability".   Second, let's call an association what it is, which is consultants pooling a theoretical $50,000 annual, and the association then becoming in some sense "LLC's new client", representing about 10% of LLC's business.  LLC also maintains other clients (who purchase development of new features) and gets foundation support, which rounds out the rest of the budget.

Ok, fair enough, but what does this new "association client" get for its money?   "How will the money be spent?" section above lists things the core team is doing already so essentially reads "sustaining business as usual".  In comparison, Zing, for instance, gets something new: CiviHR.    Well...what if the association wants a feature?

What if that feature the association wants is "change" to "business as usual"?  If so, does LLC want the association as a client? That's a bit more fuzzy, isn't it? No seriously, choose something in "How will the money be spent?" and consider if the association wants LLC to change that thing.  I know many prospective association members do want change. How will everyone react?

In theory, at least, representatives of the association will have some limited influence over LLC, but only more or less proportional to our theoretical dues as a % of the budget, similarly to a major feature funder.   Are we comfortable with that?  Or do people want more or less than that? 

It sounds like it's been already decided the association will happen.  The timeline is already in place.    But let's please both LLC and prospective association members think hard ion what we really want and will accept, on both sides, before we start filling out applications. Thoughts?

I suppose we're a bit of a unique bird, but as a nonprofit that helps other nonprofits implement CiviCRM, I'm curious if there could be a nonprofit exception of some kind.

At Lobo's prompt, I am determining how to incorporate a line item into future CiviCRM projects that will go to CiviCRM directly. We want to contribute back, support the project and help its sustainability, but our mission is to provide our services at a rate that underresourced groups can afford so our margins are extremely tight and $1k per FTE is just not in our budget.

I supported FTEs as a way of calculating dues since it is a reasonable proxy for amount of CiviCRM work, without making organizations indicate their annual revenue from CiviCRM business. I think a percent of CiviCRM is another good approach.

Number of clients isn't as good a metric to me, since the type of projects that different consultants get from their clients may vary. For example, Stoob concentrates on small clients needing help using CiviCRM, providing clients with hours or days of help per year. I concentrate on engagements that require months of person time. I don't think counting clients would be fair to Stoob.

I'm comfortable using an honour system whether it is FTE or % of revenue.

However, I really like the idea of publishing the objective metrics like Drupal does of an organization's and its staff's contribution to the project.

I would prefer to leave security things separate from the association, and I think we should have a security team with a mandate and processes similar to Drupal's.

I think that the concern around in-kind contributions dropping as monetary contributions become required/expected is real. Don't have a good solution at present. I still think we should move forward with Partnership Association.

Stoob raises some interesting prickly points regarding the relationship between various consultant providers and core team activities/practices with respect to his 'change' paragraphs. Personally I don't think that we need to resolve them before we move ahead with an association. I would say that dollars don't completely equate to influence, but that in some cases new revenue streams can enable resources to be allocated to long-standing concerns. So I don't think that 'buying change' is the right metaphor here. But perhaps it might be a way that consultants would have some influence. Personally, I would prefer for the money to just go straight to the core team to replace revenue they will be losing from foundations, and for the community to 'make change happen' through discussions that also involve other voices like small and large users and major project funders like Zing.

(Personally I have seen some nice changes occurring as the core team took on additional staff recently. CiviHR as I understand is going to be building on some of the work supporting Symfony that has been successfully introduced in extensions, and will hopefully be building a path for migrating core away from some deprecated libraries in 4.5, for example. totten has played a big role there, and I understand that coleman is helping to address technical debt accumulated through fixes that helped get releases out the door by appying new consistent approaches across the code base when fixing various bugs. And Michael is helping steward community growth and involvement in various productive ways.)

My local public radio station (probably yours too, if you have one), calls everybody a "member" if they donate anything more than zero dollars.  People give because they recognize they're already receiving a benefit, and don't want it to go away.  Speaking as an individual, I prefer that approach to anything along the lines of buying a benefits package for a price.  If the organization (a radio station, or CiviCRM core team) can be forthcoming about expenses and its need for financial support, people like me will give.

I also tend to agree with ErikHommel (if I understand him correctly) that creating a new institution is likely to have siginificant overhead and unintended negative side-effects. 

So if we as a community of CiviCRM professionals feel we should have an association, that would be a good reason to consider starting one, and to ensure that its purpose meets the needs of the CiviCRM professionals. But if we're just trying to address the funding needs of the core team -- which are legitimate and necessary -- lets' not say we're creating an association for CiviCRM professionals. Let's just say we're raising funds for the core team.

As an implementor/integrator, I am 100% behind this initiative and creating a sustainable ecosystem around CiviCRM, starting with the core team. But overall I am worried about spending too much time over-engineering this association and in the end having few providers 'buy into' it.

On calculating the proper contributions, the FTE via a 'honor system' seems to be the fairest system, tough we might have to accomodate for non-profits/coops/foreign and other special cases with a discount system - for example 50% off if you belong to these pre-determined categories.

On creating a legal structure for this association, this is going to bring a whole lot of complexities in the system that we most probably do not need, at least initially. Also, the expected non-profit status of this association is probably not going to bring in any tax advantages as the core team is incorporated as an LLC anyway.

With respect to the 'Governance' that this association could provide, we are already in a 'do-ocracy' and the core team greatly respects the voices of those that contribute the most. For 'Governance', we should probably just set a monthly phonecall for all interested service providers to discuss their issues, and then come back to the core team with propositions specifically backed by X, Y and Z. If X, Y and Z are amongst the most active contributors, this proposition will carry a lot of weight.

On the 'Certification' of service providers, this is also something that is going to add many complexities for no apparent benefits. From experience customers do pay little attention to these certifications as they do not mean a lot anyway. And existing trainings are 'end-user' oriented and certainly do not reflect the skills needed for an implementation, which are also very different than the skills needed for an extension development, which are also very different than the skills needed to build a reliable hosting platform.

On recognizing 'other' contributions, the core team already has an 'active contributors' page on the website. I would rather have them eventually formalize broad criterias and keep on maintaining this list on their own than put this responsibility on the association.

So in summary, and in line with the KISS principles: let's publish recommended financial contributions on a c.o page and send our checks to the core team asap. Let's have the core team flag listing on the service providers page with a 'CiviCRM Asssociation' badge, an 'Active Contributor' badge, or hopefully both for most of us. And let's setup a monthly phonecall to discuss 'service providers' issues and eventually come back to the core team with recommandations. This could be done in a few days, not months.

But 6 months from now, let's revisit the topic and see if we achieved our goal of bringing more sustainability to the core team. If we have overachieved and have a whole bunch of providers on-board, then we can probably spend some time formalizing things.

I feel inclined to agree with Allen Shaw that using a term like the American 'sustaining member' or 'financial supporter' might be more appropriate. This does seem to be primarily about fund-raising to ensure that business as usual can continue rather than providing a bunch of benefits.

As Joe pointed out we have 2 new full-time American staff members on the CiviCRM core team since CiviCon SF last year and they have both made a huge contribution to improving the code sustainability as well as the bells and whistles (I specified American because I'm not sure if the staff numbers have changed on the Indian team). So business as usual is actually not business as usual - it has been enhanced by the addition of Coleman & Tim.

It doesn't seem to me like Michael's proposition is about giving service providers more say or influence. Rather it is about keeping what we have going.  When I first heard Michael mention it it seemed to be about setting an expectation of the minimum that people who make their living from CiviCRM should be contributing back to the project. As Michael mentioned in his blog not knowing what the actual financial situation of the project is has always made it hard to get a sense of what is required (reasonable) from the consultants. So, setting a stake in the ground about an expectation may be helpful.

I think consultants might have fairly limited control over this money - it maybe that it is appropriate to use something like User Voice to prioritise usage of this money - e.g various proposals would be in there & consultants can use their purchased votes to say what they think is highest priority for them

My sense is that consultants are not the main providers of MIH funding but they are the main providers of CiviCon sponsorship and this will probably be affected.

This is an important and valuable discussion. Lots of really useful and interesting points and perspectives.

I'd like to add a few more from my own point of view as a small business that does some CiviCRM work, and would like to do some more, and also from the point of view of someone who has made very minor contributions to this product and community over the years I've been using CiviCRM.

I think perhaps we have managed to conflate two issues into this discussion, which might better be considered separately.

Michael began this discussion - I think - by asking the question "How can we best get more funding into the pot to help this product and community develop more effectively?". At the same time the proposed solition raises all sorts of questions about governance, and the power relationships that might or might not exist within the CiviCRM community. 

If the sole goal is how to get more money in, then there are some good idea presented above, and I tend to concur with the views of ErikHommel and others in that respect - let's keep it simpleand not get bogged downwith notions of associations, etc.

However I would argue that such an approach - whilst it may be effective and lightweight in terms if generating revenue - may be missing a potentially far more important opportunity, that being the creation of effective channels whereby the product and the community it serves can be strategically strengthened, with the goal of enabling CiviCRM to become a leading CRM tool for the third sector globally.

Open source tools like CiviCRM generally develop a community which is very much tech-focussed, and this is perfectly understandable given their evolution. At the same time, in very large part the end users of CiviCRM, by its very nature, will not be at all tech-focussed. And in between these two very distinct groups, we have a whole ecology of developers, consultants, managers, implementers, trainers, documenters, translators, etc., etc. all of whom will have some sort of stake in CiviCRM. 

I believe that, in the spirit of the non-profit/third sector that it seeks to serve, CiviCRM would do well to seek to take an inclusive approach and welcome all of these varied constituents into more effective relationships with CiviCRM in order to ensure that the strategic product roadmap is in harmony with the needs of the community that it seeks to serve.

I think that this is the mission that Michael has in his role. And I see it as critically important to the sustainable development and success of the product. My concern at the moment is that there is no such harmony, although I can see some developments happening that may hopefully change this.

I recall the development of the Drupal Association, and learned through watching that process that there is a key difference between the open source movement and the cooperative movement (which is where my thinking comes from). The open source world is very much a meritocracy, where the folks that score high on the metrics "float to the top" so to speak (and as someone noted above, "keep know-nothings out") . Whilst this approach is undoubtedly a great way to get the best minds focussed on the technical task of improving the software, it is far less useful when it comes to understanding what the real needs of the user community are. My own experience of working in and with cooperatives is that while a flat and democratic approach may sometimes be frustrating and limiting, it also brings great new opportunities for learning and development.

In my years being involved with member-based organisations I've always been a supporter and advocate of the notion of a Spectrum of Engagement. By which I mean that different people want to engage with the organisation at different levels, and a clever organisation will be aware of this spectrum and provide a range of opportunities designed to match that spectrum, and also enable people to move along it, from periphery towards the centre.

The people who write the code are one (or maybe more than one) bit of that spectrum. For many of us who don't speak code, or who don't speak it fluently enough to be contributing technical solutions (are we "know-nothings" I wonder?) that developer community is something of a closed world. But we have other - and I would argue, equally important - constituencies of practice.  And we have different requirements in terms of the services we might want (and be willing to pay for), the communication channels that we might usem and how we expect to be involved.

I strongly believe that by seeking to better understand the nature of these various constituencies, and their needs (both in terms of the software product itself, and the services that might complement the product), there is then considerable scope to develop solutions that serve the dual purpose of strengthening the community and generating substantial new revenue for the organisation that is not simply a tax on the community.

I would be very happy to be involved in developing a solution around this notion.

Since this post is labeled Part 1, I'm really looking forward to Part 2.

Having watched the Drupal Association try (and often fail) to walk the line between a non-profit that represents the entire community and an organizaiton that serves its biggest contributors who happen to share a single business partner, I'd really like to avoid seeing that happen to the CiviCRM community.   As the Drupal community has grown, the D.A. has become increasingly necessary to take on larger projects that were once handled by community volunteers.  The problem is the criticism about how funds are spent never ends and there is less interest in volunteering to take care of something.  If it's left undone, the D.A. could eventually pay to someone to do it so why volunteer?

CiviCRM has depended on the "benevolent dictator" model to get to this point and I see no reason to change that.  It might make sense to create an association that would manage certain aspects of CiviCRM and where more points of view are represented in the future, but as many people have pointed out that's a much longer, more complicated process.

I see a fee to be recognized as "Sustaining Contributor" as a logical solution to the problem that's been identified (CiviCRM's core team needs more $$), but if the goal is to raise $$ to cover core expenses, I don't think this designation should be limitted to service providers... or even organizations.  Keep the focus on individuals.  

I see contributing at a level that makes you a "Sustaining Contributor" as a vote of confidence for the core team and how they've managed everything they do to date.  I'd be happy to contribute to that, but I'd also like to see a "Sustaining Organization" designation for groups that aren't contributing code, documentation, or in some other way.  These are groups that use CiviCRM and are willing to contribute back at some level beyond what they've likely paid for an implementation and training.

Ideally, a Sustaining Contributor would convince some number of the organizations he/she works with to become Sustaining Organizations and have a multiplier effect while not necessarily increasing the costs to organizations implementing CiviCRM as service providers pass on the FTE costs.

Drupal's use of the pay to play system for http://drupal.org/hosting is constantly criticized.  While I'd like to see http://wiki.civicrm.org/confluence/display/CRM/Hosting+provider+information and http://civicrm.org/what/experts updated, as many people have already pointed out $$ isn't the only (or even most) important way to contribute.  

Putting a $$ value on other ways to contribute complicates things,  but I'd hate to see these be deprioritized to focus on paid client work needed to pay the FTE fees for an advantage in placement and leads.  Here's are some real world examples…

Both Peter Petrik and I proposed sessions for Drupal Camp Austin (http://2013.drupalcampaustin.org/sessions/#submitted-sessions).  

Nicolas Ganivet offers low cost CiviCRM training for non-profits in Denver (http://www.t4tcolorado.org/calendar).  

Developing these presentations/training, traveling to the events, and the time spent at the event all take time that could be spent on billable client work.

Here's a few potential changes to the draft fee structure that might address this:

• Lower the cost of each individual Sustaining Contributor to $500/year (or %1 of median individual income for country/region/state if the user would like to contribute less). 
• Require an explanation of contributions other than $$
• Require explanation of contributions other than $$ to be updated each year with reminder emails throughout the year (great way to track and highlight non-code contributions)
• Allow organizations where the % of FTE who are Sustaining Contributors is more than 50%?? to be listed/filtered anywhere organizations are listed on CiviCRM.org.
• Create a Sustaining Organization indication that is based on % of orgs budget or a higher set fee.  Since most orgs are already share this publicly, this should be less of an issue.  A profitable service provider who doesn't employ enough Sustaining Contributors could pay the higher set fee. 
• Encourage service providers who aren't as active in the CiviCRM community and/or only have a small percentage to FTE's working with CiviCRM to join as an Sustaining Organization and work towards increasing the percentage to Sustaining Contributors

These change prioritize active individuals who try to offer non-profits the lowest possible cost and contribute in many ways while still giving an additional advantage to organizations made up of several of these individuals.  By combining the income from an increased number of individual contributors with organizational "users", we'd likely still reach the financial target for funding core.  At the same time, by requiring each FTE be registered as an individual Sustaining Contributor we've increased transparency, lowered the barrier of entry, and encouraged service providers to get any contractors and new employees involved in community and contributing in some way as they are hired or hire contractors who are already Sustaining Contributors.  

Most of this feedback is based on wanting to avoid the preferential treatment individuals working at organizations focussed on enterprise level work now get in the Drupal community.  While the enterprise level work is very important, it doesn't have to come at the cost of keeping the barrier to entry for new contributors low and make them feel like their contributions are important.

Hi all, I totally agree with the goals of this post. I like Kasia's post about keeping it simple (at least for the 1st. phase) and the "Sustaining Contributor" approach by kreynen. My first thought was "Certified Partner" but that could send "commercial product" subliminal messages, so Sustaining Contributor fits better. 

I think the Program should take in count 4 target groups:

1. Hosting providers 
2. Professional Services providers. (organizations)
3. Professional Services providers. (individuals)
4. End users

For each group a specific "Sustaining Contributor" program can be defined with commitments and benefits.

For example, for Service Providers (Organizations).

Commitments:

- Annual contribution based on #CiviCRM related FTE's or CiviCRM driven revenue based on a good faith approach.

- Other related to training, community involvement, Success Stories reported, ...

Benefits:

- One big benefit (IMO the biggest) should be being part of the Expert List in CiviCRM's website. We receive requests only for being part of that list.

- Sponsorship discount for CiviCON

- Sustaining Contributor Logo for be included in the website, other benefits.

Alejandro

As a I read through the long list of comments, I began to formulate two questions:

• Is this about the community or is about those who profit financially from CiviCRM? I personally do not profit financially in any way shape or form from CiviCRM. In fact, being a part of the ambassador program costs me time and thus money. I would say that most community members who contribute fall into this category.  Creating an organization to get money from those that profit smells an awful lot like commercialization to me. Why stay with CiviCRM and pay to play when there are hundreds of CRM/AMS systems that let you pay to play.
• Is this going to cause a downturn in those that don't financially profit from CiviCRM?  Although NPO's / NFP's don't directly profit from doing consulting and inplementation or training, they do profit from donations and time/resource management using CiviCRM. So what I focused on is those that actually are financially sustained organizations that directly use CiviCRM to do so.  By making those that pay more, more valueable within the community you neglect those that contribute small amounts monetarily or otherwise. That's why MIH has been so popular thus far as the little guy gets a voice with their small funds. All those little guys add up to a larger voice.

So, a follow up question is that if the goal is about money for the core why is membership sculpted for those that stand to gain the most financially rather then those that stand to gain the most functionally? Why is there not consideration for a member-based organization with a nominal membership fee ($500/year) first and the rest being ancilary? I mean you want more money from those that profit the most simply create a program to help facilitate such within the goal being that those who pay to play so to speak are the ones that the core team looks to for jobs that can't be handled by the core. An RFP process with a project manager within CiviCRM that potential customers can reach out to.  The projects could be broken down into sub-projects and sub RFPs (RFP= Request For Proposal) and strip out any pay-to-play information and let the bids speak for themselves.  This creates sustainable business for both sides (the core team receiving 3% or something of contracts thus covering the administrative costs).  It also allows the community to still be a community where the rest of the organizational aspects could be handled by volunteer members (this is what we do specifically).  Such as trainings, meet ups etc. that are sanitized from pay-to-play member potential sales pitches.  Furthermore, the pay-to-play members could pay an additional fee as "corporate sponsors" where they are actually paying to play for business rather then dictating where monies will be spent.  Let the community as a whole dictate the direction with the core team directing it without influence from pay-to-players.

I think the core team's goal of having sustainable finances is important but the membership needs to be cheap for everyone and those that have the extra can then commit via MIH.  MIH is for new features and membership dues are for current features and maintaining those features and fixing issues related to those items.  I often think that MIH funding trumps the existing functionality (bug fixes mostly) as the team has to go where the money is rather then being focused on delivering quality core functionality or enhancing it appropriately (my personal pet peave of transitive relationships that came as an extension rather then part of core).

As large as the community has grown, I can't image that many of those who use it would mind being members for a nominal fee and then MIH isn't impacted and another model is used to get the pay-to-players the business they are seeking from new or existing community members.  I also think it's unfair to have the larger pay-to-players making the barrier of entry for new comers even higher and the community members from having their goals met with real bidding rather then rates set by those elites.

Not trying to offend anyone but I personally give back quite a bit without regard to any financial gain as do many others.

Sorry I'm a bit late to this one, but I've been a bit tied up recently. My feeling is that this is looking complex and expensive. 

I can imagine this thought process: How many FTEs? 10 (ouch) oh but only about half of them work on Civi stuff, and then Civi work only accounts for about 30% of our income so should we pay 5k or 3k? or 1.5k? And then do you have levels for what country the company is based in, or should that be where your staff members are? What if we run all our transactions through a third world tax-haven? ;) And to get the non-profit discount do you have to be a registered charity? What about social enterprises? What about workers coops? 

I think a better mechanism would be simpler tiers like sponsorhip. Feeling like you want to pay for gold, fine. More constrained this year: pay for bronze. Having said that it does seem perhaps unfair that a long-time contributor NFP with limited budget may have much less visibility than Mega Hosting (apologies if that's a real company somewhere) who have deep pockets and want to scoop up a load of CiviCRM business. Having such big numbers involved makes this more of a problem.

Compared to Drupal Association (was from $30/yr individual and $100/yr organisation but changing - see https://association.drupal.org/node/17748) the proposed pricing seems very expensive and I'm not convinced the proposed benefits really make it worthwhile especially for larger orgs. $10k for a bit of extra exposure? That would be a lot of marketing budget for us! But if we opt out will the community despise us and feel like we're not pulling our weight? Oh it's a minefield!

I'm also concerned as others have expressed that this risks the attitude of "well I've paid my $x,000 this year so I now can't really afford and don't really feel like I need to take a week out for that sprint" while also devaluing or conflicting with the input of folks who can't possibly pay that kind of money but donate loads of time to help move the project along. 

My general feeling is that a much lower cost membership that draws in many more organisations would be a better starting point for this. It would seem like a more positive image is created by having a large list of service providers alongside a handful of Sustaining Contributors or Supporting Partners or whatever they end up being called. 

DaveM

I'm slightly late, been a busy week!

I'd love to be part of the board, I have experience in as much and meet a lot of CiviCR end users to. I'm sure my company would be up for signing up, but we're in the midst of merging right now, so I'm not 100% sure of what that commitment will be.

Anyway, I'm not the best coder, but I excel at talking to people and making things happen, so please, really do count me it.

Chris