First off, it's very exciting to see this project. This has seemed like a glaring omission in the Drupal wheelhouse for a long time. For the project I'm currently developing, we've wanted a lightweight CRM system tightly integrated with Drupal from the beginning, so until this point we've been either had the option of using CiviCRM or building out something else that meets our needs.
It would be nice to see a roadmap for this project, so we could get a better handle on where you intend to take it. I know its difficult to put timelines on something like this, and a lot of people are probably asking you for just that, but it would be helpful to have some details on how you intend to structure the project and integrate other key D7 modules, such as Drupal Commerce and Address or, as @joachim mentioned, Profile2.
I'm also sort of curious if you're already building this out for a specific client.
Thanks a lot.
Comments
Heya Pomaking, First off, you
Heya Pomaking,
First off, you are totally right, a roadmap is glaringly absent from the documentation. I was just talking about with this with Michelle Murrain (http://www.murrain.net/ - sorta a nonprofit tech and CRM guru in the NTEN community) yesterday. We've got an internal roadmap, but we've been hesitant to put it forward b/c that's when we /really/ have to start engaging with the community - which is critical, but takes a lot of work. We chose to sprint hard in February to get some code written, as well as some marketing materials put together for DrupalCon and the NTC in March. Since then, we've needed a few weeks to focus on client work.
Our goal for early April is to publish the roadmap, flesh out development tickets, get back on the wagon of doing weekly sprints, and engage more substantively with the community.
Re: Drupal Commerce, yes, we chatted with Commerce Guys at DrupalCon and are excited about the possibilities of leveraging Drupal Commerce for donation pages, paid event management, etc. Our understanding is that the folks who've been working on the DropCRM spec (http://www.dropcrm.org/) have largely been waiting to move forward on Drupal CRM in D7 until Drupal Commerce is more fleshed out. (I could be totally wrong on this point and admittedly we haven't yet connected with Matt2000, the project lead, on where they are headed.)
What's really exciting to us about Drupal Commerce integration is that Ryan's stated that Drupal Commerce will allow you to "plug in" whatever customer management backend you want - which means that RedHen could, in theory, fit in really nicely with Drupal Commerce without that old Ubercart headache of having customer/constituent only accessible in different parts of your admin interface.
Re: Profile2, yes, we did look at this module. In fact, we used it for a D7 client project back in November. While there is a lot about it that we like, and while we're really excited to learn more from Joachim, at this point we didn't want to make our entity types dependent on the Entity API module. More importantly, given that we will need to build entity types (or at least different entity bundles) for people and organizations, our use case is in some ways pretty different.
Re: Damien's Address Field, yes, it's likely that we'll leverage it. If you look at our code, we've actually made good progress on our own "RedHen Email Field" module. We've written our own field type in this case b/c how CRM's need to store/manage email addresses is pretty different from how other email field modules work. With addresses, I think that our use case is much closer to how Damien's module works.
Finally, re: paid client work, no, we currently are not building out RedHen for a specific client. We (ThinkShout) have lots of nonprofit clients who are clamoring for something like this. And Shomeya (our development partners and co-leads on the project) has a number of small business clients who need CRM.
At this point I think that the project is probably 200 development hours away from being stable/useful enough to leverage for paid work. If, by chance, we can get some funding together to afford ThinkShout and Shomeya to do a few paid week-long sprints, we can get RedHen to that point sooner rather than later. If, in the more likely scenario, we need to keep development moving forward in smaller chunks, it could be late summer before we get there.
Obviously as soon as possible we'd like to engage with a wider community of developers to help us with code. But as we all know, projects like this sorta need to get some roots and established design/development patterns in place before it's effective to start receiving patches and so forth.
I hope that this makes sense. Please do ping us with other questions/ideas/comments/etc. We're stoked that you are excited!!
Cheers,
Sean
ThinkShout
More importantly, given that
That was a use case for the DropCRM too -- most of the people involved in this were part of the CRM spec BoF at Copenhagen. We came up with the idea of an entity bundle templating system that would provide you with a hierarchy of profile types, so you'd get your basic profile and below that people and organizations, and more specialization further down.
Cool, glad to hear that we're thinking along the same lines here
Joachim,
We should connect soon to talk through this more. Glad to hear that we're thinking along the same lines. Thinking about RedHen as a developer tool, this should be pretty straight forward to implement. Where it gets really interesting is in terms of UI that doesn't stink for end-users who want to add fields to their contact types. Fortunately, D7 gives us more granular control over permissions to edit various entity types - so we won't be in the awkward D6 boat where you were sort of in an all-or-nothing situation of giving folks access to edit content types.
Excited to talk more.
-S
Q:
Will this have sales / marketing / customer service features like SugarCRM, Salesforce, vTiger, etc.?
Will it be made as a feature so it can work with OpenAtrium?
It would be nice to define different record types as content types - companies, contacts, etc. and then build out the descriptive fields. Then having relationships between them and history/calendar/sales/etc. - SugarCRM is a decent program to study to see how a CRM could be.
For instance, if I make a sale in Commerce, I'd like a new contact record with that sale marked as a completed activity with the sale amount, date, etc. would this module do things like that?
Great questions! Our goal is
Great questions! Our goal is to develop a CRM framework within Drupal that allows developers to build out various types of CRM tools that respond to different needs. Quite a bit of our motivation has come from frustrations with all-in-one CRM solutions that try to meet the very different needs of NPOs, small businesses, etc.
We're /really/ pushing for getting more documentation put together this month. Sorry that we're a bit behind on it - but we're cranking and working hard to balance working on RedHen (one of our passions at this point) and our commitments as service companies.
Onward!
-S
That's exactly the goal we
That's exactly the goal we outlined at Copenhagen -- great to see people think on the same lines.
I'd love to help out in any way I can
I am not a developer, but I sold commercial enterprise CRM for a few years - Goldmine CRM. It has numerous advantages being a all-in-one solution. Some people study form to find their function, some know how they want to function and don't need form. It should be a balance of both. Perhaps a default company/contact centric install, and then the ability to define new entities and relationships. If you have to build everything from the ground up, then you miss out on a lot too. Good luck though, its a tough road ahead!
Sounds like good stuff
I am very keen to be able to build a Drupal based CRM and have been for two years. I don't have the skills to run archetect the system you're proposing, but I've worked plenty with teams of people to push integrated systems forward, sometimes successfully, sometimes not.
Wouldn't it make sense to start releasing parts of what you're doing already? Some of the key modules? I'd rather see the CRM work in a modular way rather than a singular monolith. I'm feeling particularly nervous from a previous post "We'll probably end up rewriting the whole application a couple of times".
So could we evaluate and give feedback sooner so it doesn't seem too overwhelming for your current team? It doesn't sound like a huge team of developers, and if you were to open up earlier, rather than working toward perfection, you could get a lot of help from us out here. And we're a lot like you. We have clients and other projects to work on to pay the bills. The majority of the community you're talking about falls into the same category in which you've classified yourselves.
Take some smaller steps and release more regularly. Drupal is an agile world, afterall.
Cheers,
Richard
Richard Sheppard
http://uk.linkedin.com/in/richardsheppard
Yes, we love iterative development!
Hi Richard,
We are developing agilely. I think that we're on the same page there. All the code is public on the D.O. project page - you can start playing with RedHen now, and you'll see that we've already begun to break out the work modularly. Re: rewriting code (ie, refactoring code), I'd suggest that that is an agile practice too - iterating in short development sprints to provide working code first, and then refactoring as necessary.
As I've pointed out, we've created some confusion amongst folks interested in supporting the project by not jumping on developing a roadmap. (Right or wrong, that's b/c we wanted to provide working code first, rather than providing some waterfall-esque specification that wasn't grounded in actual development.) We're sprinting on documentation this month though. Hopefully that will help folks plug in.
What folks can do in the meantime to help out is to brainstorm on small CRM applications/features that they'd love to see integrated in a Drupal-based CMS site. We're not going to be able to replace SugarCRM or CiviCRM or Salesforce or Blackbaud anytime soon. But there are plenty of smaller CRM solutions that could be developed for clients that could help move the overall toolset forward iteratively.
Thanks for the feedback.
Cheers,
Sean Larkin
ThinkShout
It's not so much you guys not
It's not so much you guys not having a roadmap -- it's that there already is a roadmap for a Drupal 7-based CRM. It was developed by the Drupal community, and we were fortunate enough at the Copenhagen BoF to have on board experts who have been working in the CRM space for years.
I urge you to consider the Drupal Way and investigate it, particularly its emphasis on reusable components that have wider appeal beyond the CRM project and can thus gain more traction from the community.
Total props to the CRM API group
Hi Joachim,
I pinged you in an email off list so that we can discuss your ideas in more detail. You've raised some important points that are probably best discussed over beers rather than forums.
That said, I do want to point out a few things b/c they pertain to the development philosophy that we've taken in working on RedHen - a philosophy which I think is important for folks who are interested in the project to understand. I'll start off being blunt, and then backing off - hopefully to make for an amusing post rather than a totally contentious one.
Here goes:
First and foremost, we're building RedHen to solve the needs of our current and prospective clients, so that as two separate companies, ThinkShout and Shomeya can get paid a sustainable wage and continue doing interesting open source work with Drupal. Collaboration with a larger segment of the Drupal community is in keeping with these goals. Working with the community, we can offer more to our clients at a lower price point. Our work can be more sustainable. We can do more innovative work, etc.
But at the end of the day, we're writing code that we hope to leverage for our clients. And, in my opinion, this is "the Drupal Way."
Point to any of the major Drupal contrib projects, and I think that you'll see this pattern/philosophy of development. Views, Panels, the whole Features paradigm, Ubercart - all of these major projects were initially developed by a single vendor for a single client. The developers who led these projects were actively engaged in brainstorming with the rest of the community, but they also started writing code early and made bold choices to ship working software iteratively.
We are working on RedHen transparently. We have been doing our best to engage with the NPO tech community, as well as other leaders in the CRM integration space (where we too have been working for many years - both as technologists and as grassroots organizers and fundraisers ourselves). Admittedly, now that we're more aware of the CRM API group, we will engage with that community more proactively.
But it does sorta come down the the "talk is silver, code is gold" thread that we all know so well in our little Drupal fishbowl. We've got a vision. We've carved out development time and other resources. And we're doing our best to innovate the best way we know how - which is to write code first, while also engaging with the community as we go.
Hopefully, we can soon get RedHen to a level of maturity that other developers can actively get involved in writing code with us. Hopefully, we can build a framework that other developers can leverage for their own paid client work. Or maybe the project will die on the vine (which would be unfortunate b/c we've already invested a ton into RedHen), but that's a risk that we're cool with taking.
I hope that this makes sense. Again, we all stand on the shoulders of giants when developing with Drupal. We want to be respectful of all those giants around us. We want to engage with the best minds to bring the most technology to the grassroots. And we want to write code! Since...well...it's fun and is what we get paid to do. ;)
More to come soon!!!
Sean
Whoops
I keep forgetting that all commits are available, even without a release.
Sounds like you've got it completely under control then.
Richard Sheppard
http://uk.linkedin.com/in/richardsheppard
Module dependencies
The description so far looks great and does fill a hole. I look forward to a roadmap with module dependencies because that will determine where i can use Redhen. I have some current D6 sites that cannot upgrade because they use module A that is dependent on B which uses C but C is not maintained. A recommendation for Redhen will have to include all dependencies.
petermoulding.com/web_architect
No supported upgrade path from D6 to D7
Hi Peter,
Thanks for your post. B/c these CRM features will be leveraging the new entity model in D7, it's unlikely that there will be a clean (supported) upgrade path for D6 sites. Ultimately, a solid CRM solution is going to require data import/export features - as found in CiviCRM. But we're not there yet obviously.
We'll keep you posted and will keep a running list of obvious contrib that we're leveraging. I know that folks are anxious to see a roadmap. We're busy and are doing our best to keep the community engaged!!
More soon.
-S
Glad to see some interest out there...
I was glad to see some good discussion generated here. The early April goals seem to have slipped away, but that is just the nature of these things, although perhaps there is more going than we see on d.o. Would it be helpful to your process to begin consolidating use cases under Feature Requests in the Issue Queue? There's a good number of very specific ones out there, just in the Drupal forums.
Roadmap is underway
Hi Pomaking,
Have you had a chance to look at the D.O. project queue for RedHen? We've got 20+ feature request tickets representing use cases. And at the top of this Groups page, we have links to various queried views of these tickets. We're in the project of rejiggering the way that we're ticketing (using tags vs component field for groupings), but the tickets themselves are still valid.
Progress is moving a bit slower than we would like, but we're still moving forward!
-s
Absolutely...
That's why I'm asking. I get the impression there may be some conversations taking place between you guys and, obviously, the Drop CRM folks (hoping, at least, that more than just Joachim are interested in what you're putting together) and maybe others.
It seems like most, if not all, of the items currently in the queue are internally generated, but I'll start adding my own, as well as others I have come across. I just want to make sure I'm not wasting my time or yours in doing so. Glad to help any way I can to encourage this extremely valuable effort.