Sun's blog post yesterday and some of the comments on it raise the concern that Acquia, a single commercial company, exerts inappropriate influence on the direction of Drupal core. I've been a full-time Acquia employee for the last year, was active in Drupal 7 core development prior to that, continue to be active in core and contrib as time allows, and am very passionate about wanting Drupal to be a healthy open source software project and community. With that in mind, if you feel like Dries has made some bad decisions regarding core, and that those decisions were clouded by his position at Acquia, or if you feel that I or any other Acquia employee has done the same, please add a comment here with as much specifics as possible. Please try to be constructive in your comments: it's possible that the decisions you have in mind were less influenced by Acquia than you think, and it's possible that well-intentioned people made a mistake and want to learn from it. Please note that I'm writing this post on my own initiative solely, as a concerned community member, not as an official Acquia poll.
Comments
Thanks for starting this
Thanks for starting this. I think there is a lot of FUD around Acquia's involvement in core, but there are also genuine issues (at least as far as I see it) which have not been properly discussed.
Things that do concern me about Acquia in relation to core:
Dries has had less time for core since Acquia started rather than more. This became extremely obvious after Drupal 8 opened when core development came to a complete standstill, and was only partially dealt with when webchick was given limited commit access to Drupal 8. This still leaves a four month black hole that we are not nearly recovered from. Dries' keynote mentioned that Drupal 7's first 100,000 installs happened within six months, it didn't mention that 70,000 of those were since May when bug fixes actually started to get committed with some degree of promptness again - before that things had completely flatlined since the week after release. http://drupal.org/project/usage/drupal shows this very clearly.
several people who have been regular core contributors to core have started jobs at Acquia, and gradually their core contributions have tailed off. There are lots of reasons this could happen, but startups tend to have high workloads, and three afternoons per month (if I have that right) is less than many other Drupal shops provide for community time. webchick is an obvious exception to this, but her appointment is also making up for the fact that Dries isn't around, and that there's no sign of a Drupal 8 maintainer yet. This isn't really about influence - if individual Acquia employees are given a lot more time to work on core then on the surface that looks like more influence rather than less, but sun bringing it up means I'm not the only person to notice that pattern.
In terms of actual core development decisions, while I think there were a tonne of issues with how d7ux went, I do not think that was due to Acquia as an entity. Those issues were more around extremely poor timing of the entire initiative (i.e. it started about a year or more later than it was possible to do right) - and that is not something that is limited to d7ux. There were definitely issues with the appearances and management of d7ux in relation to Acquia (i.e. I remember people being very unclear whether Mark and Leisa were working for Acquia or just being funded by them, and exactly how much development resources Acquia was going to dedicate to get things completed) but that to me is not really a problem of actual influence but perceived influence (and again, really, really bad scheduling).
The only issue (and I'll say it twice, so far I consider this a one-off) where I felt like a patch was pushed through by 'Acquia' as an entity (rather than Dries personally or an individual contributor who happened to work for Acquia) is http://drupal.org/node/723802 and I made my feelings on that very clear at the time. That issue only existed to meet conditions for large US government contractors and broke two-way compatibility for password hashes in the process. It directly served Acquia's commercial interests to have it in since they are involved in chasing many of these projects (albeit mainly on Drupal 6 which doesn't even meet those criteria..). The only reason I didn't take a 'long break' from the project due to that issue is because the person who posted the patch is a personal friend and had quite a lot of karma to burn with me, and because the actual technical issues were relatively minor in the scheme of things. Had either of those not been the case I may well have publicly stormed off the project or similar. To be fair, some of the arguments from non-Acquia employees in favour of the issue were the worst. Were I to notice this happening again, I would be equally livid - whether it was an Acquia employee or an employee of any other large Drupal shop doing something similar. I'd put that in a completely different category to changes like d7ux or configuration management (or scalability improvements or whatever) which mainly serve certain kinds of Drupal sites. Certain kinds of Drupal sites is one thing and those improvements can often end up benefiting more sites than intended, changes just to meet the needs of contractors for specific sectors in specific countries is something else.
In my short time in the
In my short time in the Office of the CTO, I assure we have talked about the need for naming another D8 branch maintainer a couple of times. This is in the works. I'm not saying it is imminent, but the wheels are moving.
You bring up a fun catch-22 here. I think we just have to trust people to be kind to Drupal. In my experience of watching Acquia, their employees act kindly toward Drupal frequently and reliably.
Yes, that MD5 issue was annoying. Thanks for calling it a one-off - I agree.
In my short time in the
I can't actually think of any single person I'd wish the role of D8 branch maintainer on at this point, friend or foe. That hasn't got much to do with this specific post though although it's come up in other discussions recently.
I realised I missed an aspect of this, or didn't put it as well as I caould. Controlling the time of a lot of people (it's getting into the hundreds now isn't it?) for 40 hours/week is as much 'influence' as any kind of imposition on technical direction might be - a different kind, but it's still there.
To an extent there's a catch-22 but I think that's only the case if you approach the problem from a FUD angle (either pushing FUD or reacting to it). i.e. there's a difference between day job work you contribute back, 'community time', and just spending free time on Drupal outside of work hours altogether - both in terms of the content and implication of the work (usually) and also perception. Different kinds of working arrangements allow for different combinations of the three (i.e. I personally have only ever held one job with 'community time', but was able to work on core patches for clients sometimes and spend a lot of my own time on it).
It might or might not be helpful to widen this discussion to some of the other shops that are significantly represented amongst regular core developers - I think a lot of people misunderstand the relationship of these shops to the core contributions of their employees. Most of the time there isn't much relationship at all at least in terms of the content of the work done, or if there is, it's because someone managed to find a job that in some way matches their core contributions, much less often the other way around. Acquia is somewhat unique in that it's the only shop that employees people with commit access to core at this point, but in other ways not so much (even size - iirc Phase 2 is about the same in terms of employees..).
Influence
I'm curious how this jives with what you said previously- that Acquia's influence was a "one off" wrt Drupal 7. I didn't pay enough attention to all of the D7UX stuff at the time, but at least wrt the overlay much/most of the work both on the original feature set as well as the critical bugs was completed by Acquia employees (and an intern), and I'm guessing a good amount was done for pay. I can't see how the overlay would have gotten in core w/out Acquia paying for large portions of it, and I definitely think it would have been left out without all of the bug fixes that Acquia's staff pushed through.
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
While the initial overlay
While the initial overlay work was funded by Acquia as well as a lot of follow-up bug fixes, some of the very nastiest bugs were fixed by casey - http://drupal.org/user/32403, a good example would be http://drupal.org/node/615130, as far as I know he doesn't work for Acquia at all. d7ux was very messy, and a lot went wrong, but I don't think it neatly fits into a pattern of Acquia pushing things into core against the community's will - which looks like the line you're taking. Some Acquia employees hated a lot of the d7ux work and stated so publicly, some other people who don't work for Acquia really loved it, some other d7ux stuff was not principally worked on by Acquians (for example I think contextual links was mainly sun and yoroy).
Acquia also funded people to work on other critical bugs that had nothing to do with d7ux (which was a massive relief to most of us at the time who'd been slogging away on that queue for months). It's likely D7 would have been an extra 2-3 months late without that help. Now, I think it's highly problematic that we got into that situation in the first place, but the fact that people like effulgentsia, ksenzee, David Rothstein had dedicated time to help resolve the last 30-40 critical bugs was not an example of negative influence (and is what prompted Moshe's blog post).
So while I don't like several things that came out of d7ux and the process was flawed in many ways, the overall effort fits into a model of contributing code (and design/UX talent) upstream, if you want to read nefarious intent into that it's entirely up to you but for me it just went a bit wrong in several places.
With the md5 issue that did not feel like an upstream contribution, but more enforcing a particular sector's (the United States government) requirements onto core without any real technical merit (see the second post in that issue). I have only seen this happen once, if it happens again good luck everyone 'cos I'll be out.
When you say "for pay" though it looks like you're objecting to people doing any paid work on core at all, this is the case?
Sony funded some internationalization improvements back in 2008/9 via CivicActions- some of that work ended up in core, see http://drupal.org/node/383954
I've also worked on several core bug fixes (mainly for performance and scalability issues, sometimes other stuff) for pay - as a result of working on large Drupal installs on both Drupal 6 and Drupal 7. Paid work constitutes a tiny fraction of the time I've spent on core in the past four years, but I'm very happy when that happens because I like working on core issues and fixes for contrib modules a lot more than writing custom code.
Does that mean that Sony or Tag1's clients are 'influencing' core development (to be less uni-lingual and less slow! the horror!)? Or are they just contributing bug fixes upstream? What about Views and Panels then? You own a Drupal shop that has employed prolific core contributors, how does that fit into this discussion?
Clarifications
I don't think we're really disagreeing with each other here, so let me try to clarify what I'm saying.
There were a bunch of people that helped squash bugs in the overaly, though in the example you mention, most of the initial work looks like it was still done by Acquians, but that's missing the point. The fact that most of the work was done by Acquia employees in (I'm assuming due to the time stamps) paid work time, and that rather large expenditure by Dries and the company he owns made it possible to get a "working" overlay into core, and Dries' position as Drupaltator ensured that the work would get in.
I think this is where we disagree. Without Acquia what I believe would have happened is that it would have been clear that the community at large was not going to step in and rescue the poorly planned overlay, and the choice would have been pushing D7 back for several additional months (or years?), or removing the overlay. The fact that Dries was able to dedicate these resources to the release is good in theory, but in practice it is (IMO) problematic. The biggest reason for this is (to state it again) that no other employees at any other company have the ability to not only fund the work (which only a select few can do, but still more than 1) but also to ensure that it makes its way into core (which only one company can do). Because of this special status as a company, what normally seems appropriate (paying for core work) becomes problematic, since they are now able to bypass any sorts of checks and balances (insofar as those exist).
"Nefarious intent"? Who is reading into intent? I thought we were discussing inappropriate influence, which isn't really nefarious, and has little to do with intent. To be clear: I don't questions Dries' intent, which I believe was to A) solve usability bugs found in the UX research and B) to GTD, both of which are, on their own, completely positive (or at least benign) intents. However, while the intent is almost certainly pure, the influence question is much more murky, and IMO problematic.
Was the influence of Acquia "inappropriate" here? I don't know for sure, but it sure feels like it was. But, maybe it would be helpful if we defined what inappropriate influence actually means. What I describe above seems inappropriate to me, but maybe we're not in agreement on what is appropriate influence to begin with.
Yes, it does mean that Sony, and Tag1, and Zivtech all have some influence over the direction of Drupal core, and that's a good thing. The issue is that none of those firms have the ability to guarantee that the work we contribute makes its way into core, and we can pretty much guarantee that our work will not make it into core if it doesn't have broad community buy in. One company, and one company only, has the ability to hold up a major release of Drupal, pay their employees to create new Core features, pay them to fix the bugs created by these well-intentioned but poorly planned/sold features, and then push it into Core with the hope that the buy-in will happen later, and unless we admit that Acquia owns Drupal, that has the potential to be (IMO) a very bad thing.
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Any examples other than Overlay?
Hi Alex,
I'm still processing all of the feedback on this post, before I'm ready to respond with my perspectives. Thank you for laying out what you consider to be problematic. I'm curious if you have other examples in mind, besides Overlay, of something you feel was pushed into core without sufficient community buy-in.
Thanks,
Alex.
not personally
I've definitely heard other folks complain about other issues (Catch mentions one above), but this is the only one that I personally had any involvement with. And to be extra special clear: I am not saying that Acquia forced its employees to do things in a certain way (it's obvious Acquia did not do that), but rather that by putting so many of their resources into the project in a way that no other company could (guaranteeing that their work would make it into core)--ultimately creating a large burdon on the core development and business communities--is problematic.
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Access and placement
Any Drupal shop could discuss the need to have another D8 branch maintainer, but only one could do so in a context that's directly tied to decisions and outcomes. This in itself suggests a lot about the different placement of Acquia in Drupal core decision making.
re:
re: http://drupal.org/node/723802 I was actually motivated by a broader concern that Drupal would not be acceptable to run for US (and other) government agencies in the near future without this change. I pushed that issue after coming across and realizing the implication of some NIST directives that no one else seemed to have noticed.
If we got into the situation where Drupal was pulled off whitehouse.gov or other prominent sites, that (to me) is extremely bad for the community in terms of our goal of having Drupal be the dominant free CMS. Having Drupal officially excluded from those sectors for being "insecure" would also feed into FUD from close-source vendors regardless of the technical merit of the NIST directives or of any specific use of a hashing function.
I admit I was pushy in that issue, and that the change was much later in the cycle than it should have been, but it was based on my own initiative, not any directive from within Acquia. Note also that a e.g. Owen and others with no connection to Acquia supported the change as well.
Frankly, here is my
Frankly, here is my thought:
Acquia can start a norm by grow a lot of developers which can take action as Drupal contributors in an equivalent of work or more than they take as a return. When Output to community > Input resources Acquia take, that's real constructive. That seem to be what community expect as a role model company.
There's a problem which community never expected. The fact is, now Dries virtually have no time for Drupal insight architecture. This have unconstructive side since it give serious consequences by demoralized community. Hire webchick for Drupal project is constructive and really good policy, but the issue remained unsolved.
Again, I love and hate Acquia for this ;)
Acquia can influence Drupal constructively, as long as they response and count it as their company cost. Acquia can invest a lot in Drupal usability or any improvement as they see Drupal lack of, push it into core modules, but don't forget the responsibility to maintain it if it is not the stuffs that Drupal community expertise. It is not resposiblity of volunteer who didn't feel comfortable about it. I see no problem for Acquia stakeholder to invest a few million dollars per year right at the community. And actually, I think Drupal need more than Acquia to do this as the sustainable way to support project. See, Linux kernel.
Drawing Enterprise is very positive, but if non-enterprise shops have to lose many focused and customer is unconstructive. We are being eaten on our long tail, I guess it is Wordpress which is not competitors. They are just up from 8.5 to 15 percent of the web this year. Right, it's not Acquia and may company competitor but eatting up work from many shops, which are also big parts of our community. So if Drupal is not interested in this anymore, go announced and tell them (and Acquia investors) Drupal is not tailored for me and them anymore. And I will shift my effort to Wordpress now.
Drupal is not only for enterprise, its have to answer how enterprise oriented development have actionable benefit from other perspective? It is good if it lower barrier of entry and help empowered individual, small shop to be able to do enterprise like Amazon, ebay, facbook, Agoda for thousands dollars. And I will admitted it is constructive.
Again, I love and hate Acquia for this ;)
Conclusion:
- Do Acquia CEO brave enough to explain why those venture capital have to give them back as cost? A few million dollars per year is not problem, it's their another goldmine, as long as Acquia can magically make money from Drupal. That's how Mr. Thomas Erickson can do it right and really help solve Drupal community problem, give back 20 full-time efficient Drupal developers (and keep incresing) to do what really 'help' not 'dictated' current Drupal developer. It will 'magically' solved this problem holding Drupal and Acquia back. Hey, Drupal framework with Apple simplicity is nice.
At the end of the day, it's just math game for Mr. Thomas Erickson. Which Drupal community watching what you do, without want to know how you do ;) ... Steve Job's magic is also fine for this.
Regards,
Richard C
My response on Sun's post...
<IMO>See, the funny thing about owning a company is that you are the company. So, a better way of asking how Acquia affected Dries is how did Dries' newfound powers at Acquia (having a paid staff), and a mandate from stakeholders to grow the project, influence his decision. But the bigger question is how did the existence of Acquia affect this process, and that is much, much easier to see.
If you take a look at the initial overlay thread ( http://drupal.org/node/517688 ) you'll see a big portion (most) of the work was completed by Acquia employees (Charlie was an intern, Gabor, Katherine, David, Dries, etc are employees/owner). Not only that, but if you look at the critical bugs in the overlay (such as the accessibility issues) you'll see once again that Acquia paid a lot of money to get the overlay into core. I can't see any other way that the module would have made it into core without Acquia paying a pretty penny (as it did) to create this functionality, and IMO it is that investment that makes it difficult to remove it now that it has been committed. Can you name another company that could not only afford to have its developers work on a new feature for Drupal core, but could be certain that its work would actually be committed? As the owner of a Drupal shop, that's one of the hardest parts about dedicating resources to Core development (we do anyway), but Acquia stands alone atm in its ability to get whatever its owners want into core. That's not FUD, that's fact. (Incidentally, me thinks we need a new Gershwin's law to cover "FUD". Not everything you disagree with in substance and/or tone is corporate propaganda, and constantly claiming FUD in your arguments just takes away meaning from the actual term, rather than helping to paint your opponent as a "FUDer")
To be clear: I am not questioning the motives of Dries in this case, and I'm not trying to say that hre gave marching orders to his staff to force this through (David Rothstein had the best written explanation of why there were so many objections to Overlay before 7 was released).
The impression that this leaves (IMO) is that what Dries wants, he gets, by paying Acquia employees to build new features for Drupal core that have little (or no) community buy in. (IMO) The assumption that the community would just support whatever Dries/Acquia [got into core] was arrogant and misguided, and I think that announcing that it will be removed from D8 will be a signal that core is moving back towards sanity, and away from undo corporate influence.
</IMO>Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Removed from D8?
Hi Alex, I am not a hardcore developer. I don't follow the IRC, commit logs, or anything like that, forgive my ignorance. The wording of that sentence is unclear to me - is your comment speculative/hypothetical? Or has it in fact been announced somewhere that Overlay is being removed from D8? Thanks.
Just my opinion
I was simply stating my opinion that while removing overlay from Drupal 8 wouldn't have any effect on maintaining it for Drupal 7, removing it would be a very positive signal.
So far as I know Dries still has no plans on removing it...
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
small core
if the concern is power and influence that's yet more rationale for a small core in Drupal 8. Less code to maintain at the top, spread out the bloat into community projects. I don't do any core drupal work (just contrib) but contrib modules are what makes drupal shine from an end-user / client perspective so I don't think it's a bad thing that acquia and other vendors are doing a lot of work that gets pushed out into the contrib space (assuming here that they are).
I'm not saying that the issues of today aren't legitimate ones but there really needs to be a push to get projects out of core and maybe fears of a consolidation of power provide strong justification. If drupal was just the core modules and nothing optional (even minimalist themes) would it be stronger today? I end up disabling most of the D6 core-optional projects outside of menu. Part of finding a D8 maintainer would involve a visionary to take drupal in this direction and draw a line in the sand as to what is truly core and what is truly optional. By namespace alone, if something is optional, then don't bother including it.
My personal take on Acquia is not that they are having undo influence over core. I had a lot of skepticism about what they (and other big shops) would do to the more or less mom-n-pop culture that I saw previously. But, they can buy up the best devs just like any shop would want to have the best people working for them. I think it's important to keep in mind that we're transitioning from a community largely built up of single-devs, one-off sites, and a few mid size shops in the D5 / D6 world. To a world with massive dev shops, crazy visible projects, even more of the brightest minds in the industry joining our ranks, and the people already there only getting better at what they know how to do in the D6/D7 world. There's been a huge community shift I've noticed even just from my first days developing in the community (2008) and as a result there's going to be hiccups as the organization as a whole essentially morphs from "this is a cool web project" to "this is my life's work" as we're seeing a lot of devs buy into the drupal way completely.
I know I've gotten a lot of people new to the community at psu asking me about this argument / discussion / thread across people's blogs. I think ultimately it's important to point out that it's a good conversation to have and uncomfortable topics are discussed openly in this community just like development topics are. While I understand that distinction and many in the community do, from those outside looking in they could construe certain statements as the community fragmenting / unstable.
Just my two cents, keep up the great work everybody.
Ex Uno Plures
http://elmsln.org/
http://btopro.com/
http://drupal.psu.edu/
[Cross posted from
[Cross posted from http://drupal.org/node/1262752#comment-4918808]
Forgetting who I work for, just for a moment, doesn't it make more sense for the health of an open source project to focus on a slightly different variation of
#1this question? Something akin to:How can we as a community ensure commercial entities don't predominately drive the project roadmap? e.g. Acquia, Lullabot, etc.
That seems like a better question to ask. With all the hoopla this week surrounding Acquia, we might be looking too narrow at a problem that could be much wider someday and we'd have wanted to plan for it. Consider this. You work in Drupal because you truly enjoy it, you work on core because you get it; once you do it's only a matter of time before a large entity wants to hire you or you want to work for a large entity. Let's not pretend there aren't some fiscal/career drivers for the work we do as developers. That would be naive.
As a community member (from core developer to forum angel who helps folks out), it seems there is a social responsibility to your project to ensure that when you go to work for these entities that you make it clear how community contribution needs to stay a part of your job. Developing the messaging around how one would deliver that during negotiation would be a valuable piece for people IMO.
It would also be the company's responsibility to understand that the community contribution is a healthy piece of any of their workforce. They can understand it or they can't. But if we hold true to our "code" not to work for companies who don't; you'll see how quickly the wells dry up. Ultimately we hold the power, folks. :)
If you need proof that model is possible you only need look at the Linux project. #1 Contributor? Red Hat. Others? IBM, etc. (Thanks @jacobsingh for that info)
I'm purposely staying clear of the other items since I don't work in core closely enough to have a strong opinion but I can tell you firsthand working for Acquia that the #1 driving concern expressed to us by executive leadership is the health and acceptance of Drupal. So I truly believe if a real plan was suggested for companies to follow and adapt to, it would be heard.
Anyway, thought I'd throw that out there as my suggestion seems to have more longstanding appeal than "Who is the company this cycle who is the offender?" - I am sure we will come roundtrip to others in the future as Drupal grows. Let's plan and be ready for it.
Kenny Silanskas
Proud Member of the Acquia Support Team
Some thoughts
I've spent a lot of time thinking about this - when Acquia launched back in 2007 I was one of their vocal defenders in threads like the infamous "Seven Million Reasons To Democratize Drupal." Although I work for a company that competes directly with Acquia in a number of areas and take issue with certain things that they do at a business level, that's how business is: competition happens, and we grow and evolve. The question of business competition is separate from the core concern raised by this issue: Acquia's unique influence over Drupal's direction. (Disclaimer: These opinions are mine, not Lullabot's, and I haven't run this past anyone at my company for vetting. If it's problematic in any way, don't blame them or assume it's anything other than my reflections. Thanks!)
The question, at least in my opinion, is not whether Dries has made decisions about Drupal that have been unduly influenced by Acquia. The Drupal community has always contained a multitude of different interests, some competing, some overlapping, all tugging the project in different directions a bit it a time. (That's one of the major themes that I tried to hit on in my Product/Framework/Platform presentation at Drupalcon this year.) Traditionally, this tended to balance out because most of the people working on Drupal directly were on roughly equal footing: either dedicated hobbyists, freelancers who found bugs, small shops seeking improvements for their client projects, companies re-contributing improvements they'd made for their own needs, etc.
Contrary to what some have said in the past, thirty million dollars or so of funding isn't a bottomless fountain of fun: even with lots of money, Acquia can't simply announce what Drupal is going to be and make it happen. They currently employ about 150 people, and that conservatively adds up to a burn rate of $5,000,000 a year just in salaries. The community has to agree and go along with it, or at least a close enough version that it's compatible, and implement it alongside -- just like we've always done.
What Acquia's funding allows it to do, though, is invest time, developer energy, training, and marketing energy in the kind of Drupal that they want to see -- and to do it with a longer strategic window than most other players in our ecosystem can afford to.
At Drupalcon this year, for example, Allie Micka of Advantage Labs offered some very important observations about the difficulties smaller shops face participating in Drupal core, or other major initiatives in contrib. Advantage Labs has been around since 2003, and its pool of deep Drupal knowledge is incredibly valuable in areas like hosting, training, and real-world problem solving. With a small staff, though, they can't spare the consistent, dedicated manpower that is required for anything beyond issue queue triage and light bug squashing.
Acquia's ability to operate strategically, with a longer wait for the payoff on their work, isn't a bad thing. If you take venture capital and you're not using it to work on strategic things that non-funded companies can't, then you're doing it wrong. When it combines with our community's "Talk is silver, code is gold" mantra, however, it can easily turn into a feedback loop that consistently reinforces the priorities of the party who can focus the most coherent energy on core. That's something we have to remain aware of whether it's a handful of sleepless, caffeine-powered hobbyists or a large corporation.
Acquia is an important member of our ecosystem. Our do-ocracy model makes it very easy for even well-meaning organizations to dramatically shift the direction of the community simply by doing what they believe is the best thing on a larger scale than other parts of the ecosystem can. The solution isn't to demonize Acquia or accuse Dries of being biased; it's to forge a more coherent vision of what Drupal is, what we want it to be, and how to balance the increasingly different needs of our community's constituents.
When we have a better understanding of the difference between what Drupal is and what some parties in our community do with it we can, as a group, make decisions about what tactical changes and choices are appropriate. The solution is to take the time to iron that out: as difficult as charting a coherent vision for the future can be, the alternative is perpetual slavery to whoever has can bring the most time to bear on our planning and development processes.
Today, in some areas of core development, that primary driver may be Acquia. Tomorrow it could be Microsoft, or Accenture, another Drupal shop, a political party, or the next rising chx or webchick. As a mature software project, we need to figure out where we're going, even if it means slowing down for a bit. The more explicit and intentional we are about our direction, the more transparent any entity must be when they want to shift it. Talk is silver, and code is gold... but planning is platinum.
Vote for Eaton!
Eaton for President.
Seriously- well put. We're definitely coming up against the clash of money and do-ocracy, since money can pay people to do stuff. At this point may we should call it a do-apitialism or do-tatorship, since the people who can justify paying for Core development are few (eg Acquia and, to a much lesser degree, a few others) and very powerful (as in Acquia and their owners controls the DA, owns the Drupal name, and has sole discretion of committing code to Core) and have no checks or balances, and thus little accountability, at all (other than community anger/outrage/forking).
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
MD5->SHA2 issue
For the record, the origin of http://drupal.org/node/723802 is not quite as it's been portrayed. That issue actually came about because I emailed Keiran Lal about (as he was a manager on the security team; this was before I joined the security team). I was not, and never have been, an Acquia employee; I was working on a government project for a small design firm at the time. As I understand it, Keiran then discussed the issue at Acquia, and I'd guess that resulted in pwolanin writing the original patch.
IIRC correctly, I also discussed this issue with Jonathan Lambert of Work Habit, prior to this patch being written, who also voiced support in the queue.
So to be fair, regardless of how the issue was ultimate handled, the desire for that change did not actually originate at Acquia, and Acquia was not the only member of the community that wanted it. Either way, I'm sure a patch provided a pluggable hashing system would be accept into core just as easily.
In my mind, this was not Acquia using it's resources to push it's own way, but Acquia using it's resources to support a desire of the community, and a fine example of do-acracy.
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
I also expressed some support
I also expressed some support in that issue (and am not associated with Acquia). I think everyone (including Peter probably!) was annoyed with this issue to some extent, given that it is clearly a "political" issue (to more clearly adhere to the NIST rules) rather than an issue which has any technical merit whatsoever (it doesn't). While there is something to be said for keeping Drupal aligned with only the purest technical objectives, I think are quite reasonable arguments for attempting to adhere to enterprise/gov standards (even occasional stupid ones) when we can, because those customers can drive users and investment in Drupal as a whole. Having dealt with US Gov security audits in the past I can understand how the security department (who most likely does not have access to password hashing experts as we do) could misinterpret the (vaguely worded) standard, grep through the code and either discount Drupal as an option, or cause disruption to projects and dissuade other potential users etc.
thanks for the background
A couple of corrections to your corrections...
We already had a pluggable hashing system in core (Peter also worked on that patch) for some months prior to this issue coming up.
What happened in the NIST issue is the implementation we ship with in core was changed so that it diverged from the phpass standard it was based on, removing two way interoperability of password hashes with those from other systems (we only have one way interoperability now), to meet the NIST standard.
This was ditching a technical/open standard for a US government one, it was not only meeting the US government one. (The other options were leaving things as they are since the core implementation actually met the NIST standard in ever way except the most superficial, or increase Drupal core PHP requirements to the point where the implementation could support both).
The fact that yourself or Workhabit may also have got involved, does not change the fact that the change only met the needs of companies in a very specific economic sector (US government contractors), or that the patch was very badly handled. I'm personally quite glad to have some extra people to blame for it though ;)
Like I said I considered this a one-off (and I explicitly mentioned that I thought the issue was badly handled by non-Acquia employees voicing support as well. Obviously I got pretty pissed off in there so I didn't necessarily handle it well either).
However this is not the only patch that has got into core that has pissed me off in terms of process. http://drupal.org/node/934050 added a major API change, broke tonnes of shit, and was pushed in at the last minute by an employee of a company whose business (at that time) was extremely closely tied to the functionality added despite repeated and very vocal protestations from people trying to get Drupal 7 out of the door. There are a few issues like this where technical considerations have gone out of the window in favour of cramming in features to match particular needs of particular sectors (distribution owners, government contractors) , however they remain quite far apart and Acquia as an entity is not the problem there. A lot of work that is funded or meets particular needs does not happen like that.
The question, at least in my
So, explicitly, what do you think the question is?
I'm not a massive member of
I'm not a massive member of drupal community and so my oppinion should obviously hold less weight.
As someone wanting to get into Software as a Service, Drupal Gardens has made me uncomfortable. I don't know about things for certain, but drupal gardens is built on a platform that others couldn't use (Unlike Aegir) and may be doing stuff that deals with amazon's cloud stuff really nicely in a way that others couldn't compete. Also they have the appearance bar that is different from sweaver.
I don't know exactly what it is that makes me uncomfortable. I think drupal gardens does a ton of stuff for Drupal and even a ton of stuff at making Drupal SaaS legitimate.
I do feel much more comfortable about Subhub competing with Acquia in this case.
So this is a potential way that Acquia could negatively influence my business. A big bonus in using Drupal for SaaS is that you get to benefit for free from the community's contributions compared the SaaS providers not using Drupal that have to build everything in house. For this to work we have to make sure we use standard Drupal modules and ways of doing things.
If I decide to put a bunch of time and effort into sweaver, I'm commiting time and resources for a future payoff. But if after 6 months of work on it Acquia released the appearance bar thing they have and then the community switched to working on that, that time would be wasted.
However, if buzzr and subhub are working on sweaver alongside me, then it makes me more comfortable that Acquia could just completely change the way I do things like that...
Does that make sense?
"How can we as a community ensure commercial entities don't predominately drive the project roadmap? e.g. Acquia, Lullabot, etc."
I suppose my feelings is that increased competition is ultimately good. I suppose this is fairly intuitive. Monopolies tends to just be bad...
(I work for Acquia) I don't
(I work for Acquia)
I don't understand your sentence "may be doing stuff that deals with amazon's cloud stuff really nicely in a way that others couldn't compete" - why couldn't others do the same stuff with Amazon Cloud?
Drupal Gardens is built in a very open way. We commit UX improvements back to the community (I know there are few that are not committed and we are trying to fix those), we allow you to export your site so you can leave Gardens if you need to. Theme builder is an exception and it was started before sweaver.
I think you are incorrect that if Acquia decides to publish the builder, your work would be wasted; This is how Open Source works. People publish things, people mash things, fork them, merge them and the result is better software.
Hi meba, Literally I totally
Hi meba,
Literally I totally agree with you, I'm just explaining why I found the prospect of going into doing Drupal+SaaS with Acquia around. I don't think there is anything 'unethical' about what you guys are doing at all. It is true that in theory others could do the same stuff with amazon cloud that Acquia are doing. But there is something different to competiting with Acquia in SaaS and competing with Koumbit for example. Because they use Aegir its really nice the idea of being able to compete but know that we're technical able to deliver a similar experience to our customers, its quite nice knowing that if we do a good Job people aren't going to be jumping ship because the whole ecosystem is not just using drupal as opensource software but literally everything. Its why personally I prefer AGPL.
This is why I mention subhub. Because I'm not suggesting that it is acquia that should change. What made me much less uncomfortable after DrupalCon was finding out that there was some competition with Drupal Gardens in SubHub. Its hard explaining why I feel like this, but if there is one large company that totally dominates in one area and you're thinking of going into that, its scary.
I'm not saying that Drupal Gardens dominates because Dries works for acquia and is in charge of Drupal. I do think Drupal Gardens dominates because it is really good, and because of its focus on UX + flexibility of Drupal. And I have no problem with things dominating because they are really good.
But its not as open as Aegir, its not as open as projects like civicrm with its agpl and Drupal Gardens shows every sign that its going to get better. Can you see how that would be worrying if you're thinking of investing money to compete?
Also I don't think with Acquia its as simple as "This is how Open Source works". Because as Dries said in his keynote. Marketting is a huge part of something being succesful. As a company gets as large as Acquia it is definitely possible for it to force technically worse software but make more money from it. So far, I do not think it has done that, nor do I think there is any reason why Acquia would, all I'm saying is that it could and so it becomes alot more complicated then "This is how opensource works". Googe + Android and everything that is happening with Oracle is an example of how Opensource communities are more completely then that when large commercial entities get involved. (Again not saying this is bad, I love acquia and constantly recommend drupal gardens to people, just saying its complicated)
many people support sun at
many people support sun at http://www.unleashedmind.com/en/blog/sun/the-drupal-crisis
at here, most people support Acquia.
我的drupal博客Think in Drupal
There is no "sun vs. acquia"
There is no "sun vs. acquia" though in this discussion.
Acquia and core
What Acquia means for the overall Drupal project is a question that's key for the project's future.
Currently 3 of 8 Drupal Association (VZW) board members are on staff at Acquia. This is not due to Acquia stacking the board with its own people. All three have been active in the DA since its early days, before Acquia even existed. Rather, in my view, it is one of many reflections of the convergence of Dries' roles and choices in various domains of the Drupal project: in the Association, in Acquia, and in Drupal core. Sure, this convergence has benefits. But it also has major risks that we all need to be cognizant of and active in addressing.
The influence of Acquia (or another company) on Drupal core may sometimes be explicit, and it's worth looking at specific patches that may or may not reflect this issue. But I think much more to the point are the larger factors of scale, resources, access, and influence.
By analogy, there's the name Drupal itself. We all through our participation and contribution help build meaning for the name, but ultimately its use is controlled individually by its trademark owner, Dries. Any company or individual may apply for a license to use the trademark for commercial purposes, subject to the conditions, which include notice that the requirements for usage may change. Basing a major company, product, or service off an external trademark implies some risk. Does Acquia have differential access to the trademark based on Dries' ownership of both Acquia and the trademark? In practice, the most high profile private branding of Drupal products and services are mainly in Acquia: Drupal Gardens, Acquia Drupal.
"In approving or rejecting proposals and patches, [Dries] gives special weight to comments made by people he trusts and respects for their past contributions to Drupal." About Drupal: Core Developers.) In practice, Dries has gathered around him in Acquia an ever growing number of the core code contributors he most trusts and respects. Included in this pattern are core branch maintainers--for both Drupal 6 and Drupal 7, the individuals Dries chose as branch maintainers were subsequently brought onto staff at Acquia. In Angie (Webchick)'s case, her work at Acquia looks a lot like a continuation of her previous work as a core maintainer.
Even with a high level of technical skill and insight, getting even a minor change into Drupal core can require months of work (assuming you aren't in the elite ranks of IRC superstardom). Contributing larger changes - like significantly rewriting a major API system - is a huge investment. Before making such an investment, any company would have to have a high degree of confidence in its likeliness of success.
Acquia has on staff all current committers to Drupal core, and talent to burn, including a lot of the inner circle of Drupal core development, backed by venture capital and a presence in every main area of Drupal products and services. Does this in itself mean that all of Acquia's core initiatives will go in while those of other companies will languish? No. Does it mean that Acquia is uniquely positioned to invest in long term core development, to shape Drupal's future with a degree of confidence that others can only dream of? I think the answer's clear: of course it does.
The role of Acquia extends beyond the company itself. Acquia has close commercial ties and partnerships with other Drupal shops, ties that often reflect prior levels of personal and code level connection and collaboration. It's easy within such circles for what are actually specific aims and needs to seem universal.
More than specific patches, what's at stake here is the potential alignment of Drupal's future with specific, largely commercial, interests. What can seem to be purely "technical" decisions inevitably have political and social implications. What do we want Drupal to be, to become? What range of needs and priorities should it serve? What future should it help us build? Whose needs will drop away because they don't seem to fit and don't have influential advocates? As core Drupal contributors themselves move in more elite circles, courted by the beautiful people, to what extent do we lose touch with our roots, with the places that drew us to this work? There's a key point of potential divergence: between what's bigger, more profitable, best for the payers who pay the highest returns, and what's elegantly simple, exquisitely attuned to the amateur, to the circle of itinerant students Dries first wanted to reach out to, to those who have nothing but the will and need to connect.
In short: not nefarious backroom deals so much as the subtle but cumulatively momentous shift in access, in what seems natural or self-evident.
Practical metrics? We could look at footprints and changes that affect performance on shared hosting; specific feature sets and the use cases they address; the composition of Drupal core initiatives, e.g., initiative leaders and their placement.
I'm currently serving on the nominating committee for the Drupal Association board and we're facing a lot of the same questions. How do we ensure diversity of perspectives and skills--small as well as large Drupal shops, users as well as developers, the world beyond the US? Is two board seats for any one company - e.g. Acquia - one too many?
What concretely can we do to address these issues in Drupal core?
One step might be new formal mechanisms for input by Drupal user and groups of different types and sizes. E.g. ensure that each Drupal core initiative builds in a focus group drawn from the Drupal community that can review the implications of options being discussed, identifying issues and making explicit the practical and value implications.
Other ideas?
good faith in good people
As a community we are trying to keep up with a project that is growing at a breakneck pace. While it is very important that we don't lose our roots and that we keep having an open entrance door that new people can walk through and start contributing in the project, it is equally important that we keep good faith in good people.
Acquia is running a bunch of strategic initiatives to try to make Drupal super successful... where's the catch? With Gardens they are also catering to super small budget sites so they are not just concerned with big enterprise builds. Potentially the middle could be left behind, but I haven't seen any signs of that.
The moment somebody starts working at Acquia or any of the other big shops in the community they don't suddenly change into another person. They are still the same people that did a ton of voluntary work to get noticed and picked for the job in the first place. In the unlikely event that the Acquia management would put them under pressure to do something they don't find ethical, I bet you that you'll start see people leaving in droves and telling the whole world why they did so.
It's important to be awake and keep our eyes open about where the project is going, but it's equally important to be grateful to those that contribute to our joint success even if it's paid with a bunch of venture capital.
--
Check out more of my writing on our blog and my Twitter account.
full disclosure
for full disclosure: my company is an Acquia partner and Acquia has been instrumental in helping our business grow especially in the last half a year. I also know a lot of the people this discussion is about in person and I have great faith in their morals and good intentions with all of the community.
I also understand that none of the above comments questioned Acquia's good intentions. My main point is that Acquia is made up from a bunch of free individuals with great integrity that will not blindly take marching orders even if they come with their pay check.
--
Check out more of my writing on our blog and my Twitter account.
Summary as of Sept. 3, 2011
Thank you to everyone who has participated on this post so far. I'm about to go on vacation for a week, so I'd like to take this opportunity to summarize some of the concerns that have been raised. As you read these, please consider that:
a) I'm trying to word these summaries in a way that captures what I perceive as the feeling of the people who raised them. I don't necessarily agree with each one.
b) I'm not summarizing the things that people like about Acquia. Please read the full comments if you're interested in that.
c) This list doesn't capture every concern raised: just the ones I've been able to wrap my head around so far.
With those caveats, here's the list:
I think each of these merits a discussion. Let's see how far we can get with threaded comments, and potentially spin off new posts if needed.
My story about disappearing from core
Regarding concern #2, I'd like to encourage each Acquia developer who feels the concern applies to you to share your perspective about it. I think the community will be interested to read about the similarities and differences. Here's mine:
Prior to 2005, I was a freelance programmer, hired by clients to build custom web applications, in some cases, custom CMSes. In 2005, I discovered Drupal, loved it, and decided to not write another custom CMS again. In 2006, I convinced some friends to start a Drupal development shop with me. My goal was to be head of R&D, developing code that was fun to write and that made us more efficient, resulting in profit margins from client work sufficient enough to pay me while letting me devote most of my time to the fun R&D work. Reality didn't work out that way: three years later, in 2009, I was still finding myself only able to make money when working directly on client projects. I had written and shared some contrib projects, including Flexifield, all on unpaid time, but did not have time to maintain any of them adequately. But what I really wanted to work on was Drupal core, and I saw no possibility for having that become my livelihood within the context of my own small company. By the middle of 2009, I decided to give myself permission to just work on what I wanted to work on, Drupal core, full time, and drop my responsibilities at my company to less than 10 hours per week. This was by no means a sustainable decision: I was accumulating debt like crazy, but I just flat out lost the ability to bring myself to work on stuff that I didn't find interesting, and at the time, Drupal core was the only thing I found interesting.
Other than accumulating massive debt, that year from mid-2009 to mid-2010 that I focused on core was the best in my career. I loved the work I was doing, and I loved the community of core developers I was collaborating with. By early 2010, I was starting to want an income again. I looked for a job posting that said Get paid to work full-time on Drupal core, scratching your own itch, with no business requirements competing with your own best judgment of what to work on. I found no such job posting. But I knew some people at Acquia were working on some pretty cool stuff, including Drupal Gardens, so I applied there, and that's where I've now been this last year. My coworkers are amazing. The work is interesting. Much of it results in contributions back to the community, including occasional core bug fixes, work on the Media module, the massive Views UI overhaul, and more.
But yes, since Drupal 7.0 was released, my contributions to core have dropped, dramatically, to nearly 0. Some of this is Acquia's prioritization (Drupal Gardens is now focused on helping get contrib projects ported from 6 to 7, in some cases with major UX changes in the process), and some of this is my own prioritization (when I do get the occasional scratch your own itch time, I've been spending it mostly on the Media module lately).
Some of the recent blog posts about the difficulty core developers are having keeping up with what core has become has been a good wake up call though. Several people at Acquia, including me, are doing some serious thinking about what we can do about it.
I mention all the above, so that you know my perspective, which can be summarized as:
For the people who are active core contributors and have full time jobs: please share how you do it.
I'm going to start a new
I'm going to start a new thread about time on core, I think this is an interesting subject that has a lot more implications than 'influence' - and if there is then that doesn't need to be discussed in the context of Acquia.
Here it is:
Here it is: http://groups.drupal.org/node/173339
Planning is platinum
I like eaton's suggestion for how to confront concern #7, so I'm repeating it here:
Some of this planning is underway across the blogosphere. I particularly like some of the ground work that catch is laying.
Bypassing community buy-in
I might have stated concern #5 incorrectly by including the md5() issue in it. I wasn't involved in that issue, so I just read it now and do not know what transpired outside the issue comments, but from what I can tell, it had plenty of buy-in from well respected developers across many companies. Furthermore, I don't think Acquia invested a ton of money to make it happen. While Peter Wolanin did the heavy lifting, and he was employed by Acquia at the time (and still is), this is the kind of issue that any of the developers who really cared about it could have done had Peter not taken it on. There was no shortage of companies and individual contractors for whom a greater likelihood to land US government contracts would have easily justified the time investment, and Dries signaled early on that he was in support of it, so there was no inside information that only Acquia had about it. I'm also pretty sure Dries would have supported it, even if Acquia didn't exist, since he's been interested in increasing Drupal adoption even before starting the company. There's no doubt other issues that many developers are passionately for, and many are passionately against, that we've navigated before, and will navigate again.
The Overlay example, however, is different, in my opinion. This, I do believe was a clear case of Dries knowingly making an unpopular decision, Acquia being the only company willing to fund the development, and the development not have happened without such funding. I don't think the "guarantee it will make it in" bit is as relevant (in this instance), because again, Dries was transparent in wanting it, so had there been another company wanting to invest in the effort, I think they could have done so with essentially full confidence that it would have made it in as long as they could see the implementation through and address the fallout bugs from it the way that Acquia did.
Thank you for stating this, Alex UA. I agree with you about intent: I don't think Dries or Acquia handled the Overlay the way they did in an attempt to gain some advantage over other Drupal companies or to piss off developers. What I think happened is that many people have been troubled for years about Drupal's poor usability, and Dries wanted to tackle that problem. But it's a tough problem to tackle in the kind of grassroots way that many other things get tackled, which is why it hadn't been successfully tackled prior to D7. So, as project lead, he tried to rally the developer community to embrace the need for usability, and he rallied Acquia executives and investors to pony up some (a lot of) resources. For the most part, I think the project is much better off for that having happened, though in his first comment, catch points out that there were problems in how it was scheduled. The Overlay was particularly poorly handled in that to my knowledge, neither Dries, nor any Acquia employee, nor any other non-Acquia-affiliated usability designer made a convincing case for the Overlay solving the usability problem it was designed to solve, which is why it continues to be such a sore subject for the developers involved. The sad thing is, my hunch is that if such usability testing were to be performed, that the Overlay would actually be vindicated as successfully solving the issue it intended to. If that comes to pass, it will be good for Overlay, and a good step towards healing, but it won't change my opinion that Dries handled that particular situation poorly. However, I'm willing to cut the guy a bit of slack: overall I think he leads the project very well; everyone makes mistakes sometimes, and I think it's better to live through some (but very few) of these now and then, than to never attempt something big and ambitious, like shifting a development community towards embracing usability.
md5()
I more or less agree with your assessment of the md5() issue, however I'll stick by the being the only industry/country specific issue I'm ever aware of going in. Some issues are very frustrating etc. but usually not for those reasons. As long as it stays a one-off I'll try to shut up about it though ;)
The whole overlay discussion
The whole overlay discussion is totally out of place in this issue, Acquia did not push it - at the end of the day, me and other members of the UX-team decided it was a good direction to pursue. Even though many community members up to this day dispute, the use of it - it has performed with minimal issues in recent usability testing. We have made the case for it several times ( http://drupal.org/node/659488#comment-2391522 being one of them), but it always ended up being ignored by personal opinions on its use. When it comes to the development, much of that initial development was done by Acquia but most the bug-fixing has been done by volunteers who are really interested in it (and not overburdened core devs). I would love this discussion not to get side-tracked on it though.
agreed
While I personally really dislike the Overlay and always switch it off, I don't think it's an example of Acquia using its influence to push something in. Actually this applies to the md5() issue too. It is something I don't like in core, that Acquia was involved in, but they were not the only actor in either case.
What people forget in all of these cases is that while core committers and several prominent core contributors work at Acquia, the vast majority of contributors to core do not, including some of the most prolific. Acquia has sufficient resources and community karma to push a specific patch through to completion if they need it - but so do lots of places including prominent individual contributors on their own time.
What they don't have resources to do, and this is the important bit, is push something through that a vast number of core contributors disagree with - because doing that more than a couple of times could leave them picking up the pieces if those contributors get pissed off enough to stop working on core in their own time. It is possible that in two or three years the landscape will change and this will no longer be the case, but it's far from true now. So even if you are reading this thinking the Overlay was an example of that, think about how likely it is to happen again in the same way.
I'll also say the main issue with core is absolutely not things getting in that shouldn't (it is anissue with core but not the worst). The primary issues we have are things not getting in at all due to lack of reviews.
I don't follow...
Can you point to an actual issue where the UX team, and not Acquia staff, took the lead on building out the overaly? Also, can you please point to any specs that you or any UX person created, other than http://www.d7ux.org/d7ux-initial-concepts-direction ? I definitely did see that you chimed in that the overlay needed to be tested (and still does), but I didn't see any actual action. The same goes for "most of the bug fixing was done by volunteers": I saw a few volunteers helping, but the vast majority of the work on bugs seemed to be completed by Acquia staff (Katherine, David, Gabor, etc). If you have some specific issues you can point to that I missed, please point them out.
But this is where the real problem lies: Dries, using Acquia's staff, was able to push this in without any testing, then demanded that we test it to see if didn't help. This sort of Orwellian strategy is used often in foreign affairs, where it's called creating "facts on the ground", while in politics (and other areas of life) it's referred to by the latin fait accompli. IMO, this is not the way a well functioning Free and Open Source Software project should work (fait accompli are anti-consensus decisions, and thus inherently anti-community), and it's hard to ignore Acquia's role in this departure from Drupal norms.
Also, I think your tendency to state your own opinons as facts and others opinions as "personal opinions" is narcissistic and arrogant, and it's something I also do fairly often. Let's stick to not trying to use "But I am THE expert!" types of arguments here, since we all have different opinions on what constitutes a "UX expert" (I fall squarely into the "less books, more experience" camp).
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
I have already pointed out to
I have already pointed out to you that Casey fixed several very tough bugs in Overlay, including links to an issue. Did you not read that or have you forgotten?
You point, you prod
Yes, you did, and thank you for stating it yet again. I guess it wasn't clear, so for those who are confused, "most" != "all". Yes, there were other volunteers who worked on overlay, and yet Acquia paid for "most" of the work. I guess the "most" could be changed to "the majority", but it depends on what % you'd consider "most" (majority would be 50%+1, most could be anything from 50%+1 all the way up to 99%), and I certainly am not about to do an exhaustive study on the numbers of lines of code contributed by all parties.
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Some of the very hardest to
Some of the very hardest to fix issues were tackled by non-Acquia employees, including on issues where they "took a lead" - for example one which was a ground up rewrite. Since at least one of those issues was already highlighted in this thread, it was strange to see the same question asked again without referencing it.
If overlay was an API...
...I'd support it fully. In fact, my business partner (Jody Lynn) worked on a different solution to the popup issue in an unrelated issue, though that never received much traction. Anyway, for better or worse the overlay is probably the most widely tested modal popup, at least in regards to accessibility. If it was possible to utilize the functionality of the overlay without having to buy into the entire feature then I think it would be a very useful core UI "helper", but as it stands, it's a bloated and not-very-well-thought-out feature that IMO does very little to help with the usability issue it set out to solve (loss of context). IMO, editable fields is much more relevant to solving this problem, but I think a combo of contextual links, in-line editable fields, and a much more selectively used modal dialog, would actually solve the context issue.
Also, this brings up another sore point: that I don't think Acquia (or the UX folks) did much of any outreach to the people/firms that were already working on this issue. Did anyone try out any of the DevSeed admin UIs to see if they were better? Did anyone reach out to the people who maintain the modules that are most similar to the UX modules that made it into core (like all of the modal dialog modules in contrib, like Sun with the Admin Menu)? How about to the people who already had posted patches dealing with this functionality (like, for example, the patch of Jody's that I linked to above)? I don't think anyone did, and instead we were essentially told by some "experts" that the ways that devs were already trying and testing and patching things were not useful. So, part of the issue is: what else was considered to help solve this problem, and why is there a persistent assumption that Drupal devs don't care about usability (despite all of the UX modules on d.o.)? Usability is not a sea change, our firm's devs and designers deal with it every day, as do many other devs and designers, but shoving one person's idea (or a couple of people's ideas) of usability down the throats of everyone else certainly seemed like a sea change, and not in a good way.
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Great rundown...
I think you've distilled the conversation perfectly, though I do have a few comments and I think there should be an additional item added to the list.
In regards to #3, I agree with the first part, though I'm not sure I agree that core would be much more maintainable without overlay (every module does add some burdon, but I don't think overlay adds more burdon than any of the others at this point). I think David debunked this thoroughly enough (several times) in the issue Properly test the overlay to determine if it belongs in core or contrib. I'll respond more fully to this in the response below on the overlay...
For #4 I'd just like to point out that I am not a core developer, and neither are many of the other people complaining in the post above, yet we still have complaints. Basically, I only heard about the overlay once it was actually in core, and was horrified by what I felt at the time was a terrible implementation of a poorly thought out implementation. Incidentally, can anyone point to any sort of spec for the overlay?
The item that I think is missing from the list is talked about by jbachana in this discussion, which is: what effect will a real or perceived dominance of Acquia over core development (or any aspect of the community) have on the overal Drupal ecosystem? The flip side to that questions is: what does Acquia's move to compete directly with (and against) the entire "federated ecosystem" have on core development (or the adoption of Drupal in general)? If ten more prominent shops took the DevSeed route (e.g. deciding that they needed another core project to build their business around), what would the effect be on Drupal core?
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
A Drupal world without Acquia?
Let me posit a different angle for this. Suppose all of Acquia's work on the Drupal project is beneficial to the community and all the user base? Imagine if 10+ FTE's are applied on behalf of the project by part or fulltime work done on Acquia's clock? 15,000 - 20,000 hours of work, all for the benefit of Drupal...
If indeed what Jeff mentions above is true that Acquia has 150 people on staff, that factors to more like a $10-15 million run rate, adding in operational factors.
What if Acquia no longer existed? 1 year? 2 years hence? 5 years? What vacuum would that create in stewardship and forward-motion of the project?
Drupal is a brilliantly successful project, which in itself is historic. The other remarkable thing about Drupal is the entirely federated approach the project has taken, with thousands of contributors (yes, dozens at the core) working toward a common goal of making Drupal the best it can be. I bet it could survive that kind of 'correction' - but it is something worth considering that a centralized body that works on Drupal could reverse the tide of federation that made Drupal so successful in the first place...
Joe Bachana
First Employee at DPCI
1560 Broadway
NY, NY 10036
212.575.5609
www.dpci.com
What I believe we should do
What I believe we should do is get some actual data in this, to see how "companies" have been involved with Drupal over time and also learn from other communities how they made this into a success (Linux core dev is largely funded). I am not so much concerned with Acquia's influence, other than they being a fuel line to many of Dries his product feature ideas.
What concerns me greatly is the culture, that any company dedicating time to end-user features that don't receive everyone's buy-in is considered a bad practice. We need to realize that UX work, if you like it or not is very opinionated - we have to make choices, and any choice will have a number of people who don't like it (even if we have compelling arguments). That should not be equal, to a company pushing it. And when we want to pursue radical and perhaps even innovative UX solutions, it is only natural to be met with much resistance.
I believe our worry is not so much Acquia, but how to channel company time contributions towards Drupal core. Any company that can channels a lot of time, will have influence and Acquia is unique in that because of Dries. But not not very different to Lullabot a few years ago, or Sony was when it comes to i18n,CivicSpace with the installer and perhaps even NowPublic in D7. It is a natural progression, and I would like Drupal core in general to be more open to the idea of companies contributing time to much loved improvements and very controversial improvements.
I'm jumping into this
I'm jumping into this conversation a little late with an ultra simplistic opinion. It's not uncommon for an open source project to be largely directed by one, sometimes a handful, of bigger companies. If development really is being sidelined or being "bullied" into directions that people don't like the project can be forked. Just two cents.
Fork = last resort
While forking must always remain an option, as the ultimate check against unilateral power, I think Drupal continues to have an opportunity to be a project that doesn't go that way. If you look at the comments on this post, there's a relatively small list of concerns, well below the threshhold that warrants a fork (IMO). Furthermore, I believe (perhaps naively) that Acquia wants to be a good member of the community, not a bully. My hope in starting this post is to identify where the community feels bullied or where mistakes were made, and if the relevant parties can learn from those mistakes. If this process goes well, then Acquia also has the opportunity to set the example for how other large companies that enter the community should act. It would be a shame for such an opportunity to be squandered.
I'm by no means endorsing a
I'm by no means endorsing a large scale fork. Drupal is open source, so if a company relies on Drupal but doesn't agree with the direction of the project, they can fork internally working off of an older branch. I have a lot of faith that Acquia and the other big Drupal shops know what they're doing. They've obviously been wildly successful so far, so I assume they will continue to be.
Here here.
Back when Dries announced The Elephants are Coming I didn't really think of Acquia as "an elephant". It's obvious now that Acquia's combination of money and influence over Drupal means that it is, in fact, an elephant. BUT- it should be equally as obvious that it is not the only well-funded company that will use money to exert influence on the project, and I can pretty much guarantee it will be the elephant with the most interest in keeping the Drupal community growing. So, I'm with you 100%: we need to take this as a learning opportunity, and work to ensure that this opportunity isn't squandered (I can't imagine another company in the future being as open and honest about these sorts of issues).
A big issue I see here is the fact that, for better or worse, only Acquia employs Core committers at the moment. This may stop being the case in the near future--with the emergence of 1 or more Drupal 8 co-maintainers--so it seems like a good time to address this part of the concern...
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
If there is one Drupal 8
If there is one Drupal 8 co-maintainer, that will be a full time (or more likely one and a half time) job. Finding someone both capable of doing it, and able to stop doing billable work for the next 2-3 years is going to be extremely difficult. This needs more discussion (not necessarily in this thread) but as far as I know (which isn't that much) we are pretty far off seeing a Drupal 8 co-maintainer - could be several months yet.
I think the D8 initiatives
I think the D8 initiatives have done a good job of spreading core influence over a number of companies, and even geographically, to an extent.
some observations
In contrast Matt donated the WordPress trademark to the non-profit WordPress Foundation. http://wp.me/p4oB3-9ie
http://drupal.org/about highlights or makes prominent only one name while http://wordpress.org/about/ has a different approach
Drupal org also seriously lacks for the community things like http://brainstorm.ubuntu.com/ or http://wordpress.org/extend/ideas/
Is the trademark a big deal?
I'm not sure how I feel about Dries/Acquia maintaining ownership over the trademark, but it does seem like something that should be handled by a neutral party.
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
some minor observations
I wanted to edit the title to "some minor observations" but since you replied it did not allow edit.
The minor observations is about the mindsets, nothing serious. And it was not the only observation.
"Is the trademark a big deal?" - In case of WP (quoting Matt) "This means that the most central piece of WordPress’s identity, its name, is now fully independent from any company. This is a really big deal."
Just an observation, and Drupal and WP can and do have different philosophies :)
BTW
Very well said and glad that someone said it. Most people actually switch it off as far as I know and use the Admin module that is why that is the most downloaded admin module - if overlay was a downloadable one we could find how much that is used and thus "usable".
I am at 50/50 with this. I
I am at 50/50 with this. I find cases where the overlay is well responded to, me personally i dont like it because it seems to slow down page load, but that could be because this an early implementation of this idea. Customers really have said a lot of positive things about the new admin interface that is a part of d7, which is always what i am concerned with much. I can always disable overly on my dev environments, build things out in features then import them onto customer sites.
Humble thoughts
Usability is a wide term and imo, if Drupal was poorly usable it would not be in so much massive and wide adoption and usage from the beginning through versions 4x 5x and 6x
The tests which involved "test" users were not the actual users who surfed net, choose a cms, download it, and install and run it mostly for their own or a small or medium site - the bulk users. Their feedback are available in the forums and issues lists, a data mine which if scanned and analyzed can give actual usability needs - these essential and vital users never felt or demanded the need of any stuff such as the Overlay. In fact many used and liked Drupal as it did not alienate the admin and user interface : Overlay killed this convenience so that now to see how an end user sees your page you have to switch to and fro from the overlay soft pop up to the actual page that end user sees. And if one was to go by the so called test recommendations, 3 to 4 years ago http://drupal.org/usability-test-university-baltimore-community-solutions recommended WYSIWYG in core as the first recommendation. This was not prioritized.
A male and a female were hired (cant recall their name) without letting the community at drupal org choose, and these so called experts had no prior experience of handling something so complex and massive as Drupal. To impress the community they started preaching that user exp. is broken, and recommended the Overlay thingy. They actually killed the usability that made Drupal popular. They had some buzz words and some flashy demos and were amazingly successful in brainwashing some of the important head honchos. The so called test that was done much afterward with some dummy users was to test only the admin users, see http://drupal.org/node/1175694#comment-4564172
and so I asked in the that above thread :
Can the actual users, also known as end-users, or members, or auth members that is the mass for whom we build the site and who use the site day to day be tested ?
Is it as easy to add text or image or webcam picture as in facebook with minimum of clicks? Is it as easy to find my contacts or persons I will be interested in?
For example, I could not figure out how to position the image, left right or bottom to text, I uploaded in Drupal 7.
User experience is not so much what some self proclaimed UX experts "claim" as it is what the mass users feel who visit and use the site daily.
As admin or no 1 user or someone who has to use shared hosting and pay bills for it I find Drupal 7 with its Overlay takes lot of space, lot of CPU resources etc - somewhat impossible to run compared to 5 or 6 and this is not so good user exp for me. Please read this article http://anti-mega.com/antimega/2008/08/15/this-is-not-my-beautiful-house
Wordpress was slow to sap up the main and brilliant devs into its company, and probably when it has done so it has stagnated somewhat. If the brilliant as well as time-and-code contributors are sapped up by a company innovative development suffers. While it is good to have less bulky core, the mass, the actual mass (and not Govt or some corporate clients) are looking for features out of the box, so that they don't have to install module after module, and once they have installed they expect and need not to run after upgrades and if upgrades are needs they need point and click convenience, and backward compatibility (yes you need to carry some legacy baggage too if you do not want a broken user experience, those with such broken will eventually shift to an alternate cms, irrespective of whether it has a small or big core so long as it runs easily in shared environs and do not eat cpu).
Drupal was born not out of business needs and that's why it was noble at that time, there was no one (or a few) company to rule - so its business model gradually grew and flourished. However, now that Acquia is there it will not have innovative features that could have been under circumstances that led to the birth of Drupal. Also, it will eventually supress other drupal companies offering similar services or stuffs at similar price points - for example, if I have sufficient dollars to spare why the hell I will go with another hosting when Acquia hosting is there with all the drupal key and core persons and the original drupal team's assurance. There is incentive to code if one can join or is in a company like Acquia but the days of coders who had some day work and contributed path breaking or brilliant new codes in the night are gone. Not just in case of Drupal, but overall in the net. There is no incentive for the hobby coder - worst his code may be used commercially by Acquia or the like without him getting a penny (just as many modules are bundled with Acquia distro of Drupal and those module makers donot earn anything). Hobby coders or small teams - one or two or three members teams bring about the most innovations. So innovation is lost actually for ever. Those who code today must do it for money to sustain their family, and thinking out of the box usually is not possible in this scenario. They will also probably be want to be hired by a Drupal company or the best - the Acquia.
In 98, 99ish coding was act of fun and benevolance and noncommercial love - so we had Geeklog, e107, Drupal, WP, phpbb, phorum, smf etc and none of the like was produced by big companies like Microsoft or Google. CMSes ruled the net as free and opensource projects and still rule to some extent. But now the actual rulers are monopoly giants like FB and the big G - its all about money. And there is no such more usable interface and user product such as facebook with its 700 million users, with G+ somewhat catching up.
Todays' ruler products are no longer hobby products like Drupal or phpbb but products with commercial mindset from the very beginning (either manifested at foundation or expressed later). Thus Acquia has a shiny and attractive website and much more easier for even newbies to have their choice of drupal flavor while drupal org is lackluster or not much aesthetic and unduly cluttered and complex (not just across various drupal properties like Gardens, drupal dot com etc but also among other CMSes like WP, Plone etc) - compare the two download pages - http://drupal.org/project/drupal and http://acquia.com/downloads, and thus probably the future of Drupal is with Acquia - a bubble phase will come or probably we are in it - D7 D8 or till D9 - then gradually it will die. There will be more systems like FB or G+ or maybe these two will rule, Govt and corporate clients will have been used up (you have only limited number of Govt all over the world) and many companies will be using more of the social media instead of a cms to interact (while probably keeping just a sort of big or small brochure site out of a cms) - a trend that is almost obvious and very unfortunate - FB comment plugins which is replacing even Disqus. The generation that is now 10 or 11 years old and do not have examples of Geocities or Tripod in front of them, but consume more and more of FB and Youtube , will be less and less interested in making small or medium webs of their own as they grow up. Unless of course again some hobbyists come with something new or with a new twist. Companies like Acquia can hardly think "new" or give a fresh and new twists as these are more of service providers, marketeers and business-builders. Drupal core matured and Drupal was was used by masses for the brilliant and/or useful modules that accompanied it. While you may be now gearing up cleaning of the code, or be heading for an amazing small core or doing smart apis there has been no "innovations" like Views or CCK or OG after Druapl 4x-5x. Lack of such "innovation" ultimately leads to stagnation and finally extinction. The company can still survive with its clients though! Maybe!
Yeah...
To quote someone (I won't name him :) ) Views / CCK changed paradigms. You don't expect that often. These modules evolved a real lot, Views 3 vs Views 1.
That said, Entity API - Field API in D7 is probably a paradigm shift too.
Rules module is definitely another thing that enabled non-programmers to do things only programmers could do before. Token is like that too.
Maybe Drupal Commerce is not changing paradigms but it's innovative nonetheless.
re: Drupal8 maintainer
I agree, Drupal has grown big enough to merit a full-time maintainer. webchick is an historic 'Paul Bunyan-like' personage that she did all that work on D7 as a volunteer. However, to get this right, the project needs to hire someone.
Rather than that person working at any individual company, this should be a full time job (or a couple of maintainers, as Dries mentioned in Drupalcon Chicago) managed out of the Drupal Assocation. In fact, that person should explicitly NOT work for any commercial enterprise through the term of the contract.
I'm probably the newest of contributors on this list so perhaps the smallest voice. While I've been performing Drupal projects since 2006-2007 I have only in the past year become increasingly involved in contributions and volunteerism to the Drupal project. I believe that if we can somehow get the thousands of other 'latent' members of the community active and that the Drupal Association focuses all of its energies on coordinating this vast array of resources, then Drupal will be even more powerful a platform than any in history. The thinking "well that company over there has got it covered" is exactly what we DON'T want to happen - the thinking "I am responsible" and "if I take I must give back" is the thinking to be encouraged.
What seems to matter at most in the Drupal Maturity Model (there, I said it, forgive me) is that the project needs improved operational protocols and centralized organizers who do not have power over the community. Thats best accomplished through the DA 501(c)3 entity than through any commercial enterprise, however beneficent Acquia (or Lullabot, or Phase2, or any other brilliantly amazing and successful Drupal shop) is.
Joe Bachana
First Employee at DPCI
1560 Broadway
NY, NY 10036
212.575.5609
www.dpci.com
DA can't get involved in core code
It's an interesting thought, but the main issue here will be that the Drupal Association is by it's statutes only supposed to support the project (e.g. infrastructure, events): it's ok to sponsor development work for our community infrastructure but it's not ok to pay for work on the project itself. This was done to make sure that the bottom up community - do-ocracy would stay in charge.
So if the next core maintainer would have to be employed by a neutral 3rd party, it could not be the DA.
--
Check out more of my writing on our blog and my Twitter account.
Im all good with Acquia, i am
Im all good with Acquia, i am open to a little competition. I think Acquia as practice does a better job at upkeeping things they have initiated better than others. There are things I do different than acquia, but hey thats how the marketplace works.
Just pollish
I'm glad this is brought up.
Since Drupal/Dries/DA/Whoeverincharge seems to care more about its marketing value, probably inspired by some other fastgrowing big (some not so) open source projects there was as a result the need for pollish.
I understand that to some extend. From technical design philosophy its bloat. From marketing/front-ed usability perspective it's most wanted. Adding a "wow" factor to Drupal core. Well, that is in itself a good thing. Until now no graphical design minded webbuilder is ever to choose Drupal over WP/CI/CC5 or the like. Just because until D7 core looks arent apealing. On a mac just plain uggly ;-). But now this pollish medicine makes Drupal core technically ill. Rip it out. Make choices. If that means Drupal core is rock solid, maintainable but ugly-on-a-mac, so be it.
Drupal websites
Yes, who cares
So, the history here is that lots of things wouldn't have happened at all if it weren't funded by companies. If you care to dig, the US Military is indirectly responsible for a large part of Drupal's growth.
No other entity, including a rag-tag band of individuals who sacrifice at the altar of sleep/income, can match the contributions of companies (including Acquia) that fund contributors through a mix of direct day job time and total-compensation-package "we work on contributing" company cultures.
I cringed when I read Moshe's post, because that DOES highlight the fact that there need to be very few people in the room to make decisions. But even that is a side effect, and is also a "don't care". It would be the equivalent of asking if Vancouver exerted an undue influence on core because people could easily meet and discuss things face to face.
Nedjo touches on the more important points: if Drupal doesn't focus on individual humans installing Drupal, seeing if it meets their needs, and some of them potentially climbing the learning cliff, it will be in bad shape. The Snowman Project is about the only thing that might bridge that gap, since there are few companies that actively advocate for the self-hosted end user / beginning user (if I hear "site builder" one more time, I will scream). You can squint your eyes and MAYBE argue that pieces of Acquia Gardens might be re-usable for the beginning user, but I haven't really seen it. So, the focus on consulting builds / enterprise needs as a subtle undercurrent is the main danger IMO.
Drupal and the Drupal ecosystem will continue. It was explicitly designed to be an ecosystem of lots of companies around the world, because that's how large the opportunity was (and continues to be). If one company can control everything, it means the opportunity has shrunk.
Governance, please
Even if the answer is "Yes" to the question of the post, what can be done about it? As webchick reminded me of when I talked to her about governance in Drupal in London, there is always forking the project. But I am sure almost everyone knows that any significant forking would severely hurt the project. But in reality, that is the only official power any of us has; well maybe some technical power some few have.
So, the question is not whether Acquia has too much influence or not, it is what actual structures are in place to ensure the Drupal community is represented in the decisions made?
There are no formal structures at all, really. There are many customs and traditions that lead to loose consensus based decisions, but all we have is the benevolent dictatorship, which is really just a structure of seniority. There is the do-acracy, but I don't believe it scales at this point, and there are no checks or balances for it.
Most of us would not accept these structures in our civil governments or in many other aspects of our lives, especially the dictatorship part. Governance should not be a system of trust like Drupal currently is, it should be a system of opportunity (ie checks and balances), much like computer security.
My assumption would be that most of us are worried about the original question, "Does Acquia have too much influence", because we are weary, and somewhat mistrusting, of large corporations (and somewhat rightfully so). Maybe this manifests itself in pointing out bad decisions about what was put into core, or who worked on what, or how much time was dedicated, or just how many people work for Acquia. But we shouldn't have to depend on our trust of Acquia or Dries or webchick or anyone to ensure that Drupal is still a community project and that there is equal representation.
That's my 2 cents.
--
zzolo
some suggestions
Revisiting the issues and various responses here and other, I have some suggestion :
Simplify the entire operations of Drupal and Drupal related things
To this end - let there be just two domains to memorize: drupal.org and drupal.com
Drupal.org maintains a core and everything here is free and opensource
Drupal.com has 2 things :
self hosted blogs or webs (free and paid) - which has now a rather long name of d r u p a l g a r d e n s
branded paid services like Acquia and others (which may have some first-time-customer-catcher free services)
Now see :
drupal org
Drupal org maintains a core that is just a core : user registration, nodes, security, multisite-single-sign thingies, core updates
Drupal.org also maintains list of drupal-org-approved modules and themes
Move everything to modules : main modules : blog, forum, og, views, cck, album, profile, privacy etc && other modules : overlay, admin, color, geo etc etc or may just forget the division of main and not main
drupal com
Drupal com has various flavors or distros or one click installer packages for example:
drupal for individual blog (copy shamelessly wp features), drupal for govt, drupal for ecommerce, drupal for social net, drupal for this and that, probably a dozen - make the list not very long neither too short
How things are packaged or different individual flavors can have here their own issue lists and bug trackers as to what goes there or not
There can be even packages of same function from different companies : eg Acquia ecommerce, Lullabot-Ubercart ecommerce (just fictitious examples)
Thus the drupal org maintains, updates and bothers with the core by core maintainers
Rest of the stuff user interface, modules, themes are dealt by the community and/or company/companies
Drupal org maintains list of these - in case of community-built stuff it points to itself, in case of company-built stuffs it links to itself/third party sites
We should also meet a simple 3 point goal of :
I think keeping the acquia
I think keeping the acquia operations seperate is a good thing, although I am not scared of competition. What they did with gardens is actually not all that difficult to pull off. I have something similar that I use locally for startups / low-end budget customers, http://wembassy.com I probably went about the same problem differently(Using Aegir to do a lot of the back end stuff), but the result was almost the same. I like the things that Acquia puts out because its a good spur of ideas and making our sites more usable, easier to manage, and overall a better service to our customers should be our number one goal at all times.
I think the thing that many
I think the thing that many forget about drupal sometimes is that Drupal can be pretty much whatever you want it to be. With the hook system you can get drupal to jump through all kinds of hoops and even if you have to do 10 - 20 hours of work to customize a base drupal install to what you need, just think of how many hours ahead of the game you are because you started with drupal.
Clarifying How Acquia Works
A very constructive thread, thanks to everyone contributing.
I would like to clarify some things about how we work at Acquia. I am the CEO, have been since January, 2009 and was a founding member of the board of directors. Any key decision that we make as a company involves me to some extent. With that said, at no time have I ever been involved in a decision about the technical aspects of our contributions to Drupal Core, or even contrib modules for that matter. Naturally, I am involved in determining how many resources we can afford to allocate to any given projects. In the case of Drupal contributions, I listen carefully to Dries about what he feels is needed to do, in his opinion, the best things for Drupal. The net on this is: the discussion should focus on not if Acquia has undue influence, but rather does the community agree with Dries' guidance, and now with the creation of the office of the CTO, and consequently with the guidance of Angie and Moshe who are very involved in this.
One of the primary reasons I joined Acquia was the constructive nature of and healthy debates in the Drupal community. I hope this continues and I am proud to be a part of it. Acquia is committed to sustaining a very healthy ecosystem around Drupal, where we are but one player. I personally would also like there to be little mystery about how we make our decisions. To that extent, I would like to invite any concerned individuals to come and spend time with us, observe our meetings and come to conclusions not based on what is imagined, but rather on the way we really work. Send me an email if you would like to come to our office. Tom@acquia.com.
--------------------------------------------------------------
Tom Erickson | CEO | Acquia
O: +1 617 669 0827 | M: +1 617 669 0827
53 State St
Boston, MA USA
Thanks
However, the myth buster at http://drupalmyths.drupalgardens.com/node/256
says: Acquia supports Drupal 6 and above, supporting all modules including custom code. Acquia is the company to go for Drupal support.
So why do we need to go to any other company in the ecosystem?
Some other mysteries :
How the UX and overlay guys were chosen bypassing the community at drupal org, where announcements were made only after choosing these guys at some other obscure sites
How is the code of theme builder of drupalgardens still not being "open" even after some 50,000 dg sites always under some pretext? Are these codes and Mollom bg codes available on an office visit :)
Why Drupal 7x no longer supports shared hosting as smooth as Drupal 6
Why pages like these are not fostered - examples http://brainstorm.ubuntu.com/ or http://wordpress.org/extend/ideas/
The office may be transparent but some of the outputs or effects of the office on the community are opaque or so it seems, that's why all these talk.
The fact of the matter most
The fact of the matter most OpenSource projects end up with a split of a commercial Entity and a Community Entity this is demonstrated by what RedHat Linux / Fedora . Centos now is. This is not a bad thing as they all have their place. Even if Acquia terms itself as 'thee' Drupal support company, I can count at least 100 customers that they did not get because of my efforts and I am sure each decent and competitive developer could do the same. There is more than enough fish in the see and the fact is if you dont like the direction of something, become more vocal in the queues early on. Take an active role in what is going on and then you will have a say, that is how community projects work.
Challenging the Community
We will revise the Drupal Myths statement to more accurately represent our positioning. I was not aware of the statement, and in fact have not had time to read much of Drupal Myths. Thanks for pointing that out.
At the same time, we are a commerical company and will have a number of initiatives that help us succeed. We still have not determined the longer term disposition of the theme builder in Gardens. It continues to receive considerable updates. At the same time, we offer free use of it, and free export from Gardens -a concious decision that contributes substantially to the community. As you mentioned, thousands are taking advantage of that, something we pay real dollars for. No one else in the world does that - open source or proprietary.
The other items are all Drupal community decisions / issues, and the primary reason for my post. It's time to challenge the community, including all of the people in the post here to create the pages that you want to market Drupal more effectively. Ubuntu and Wordpress are controlled directly by Canonical and Automattic, respectively. This thread as I read it, is a discussion about not having that situation with Drupal.
--------------------------------------------------------------
Tom Erickson | CEO | Acquia
O: +1 617 669 0827 | M: +1 617 669 0827
53 State St
Boston, MA USA
Correction your not the only
Correction your not the only one in the world who does that. I have a platform that is very comparable to what your doing. Atm, im not doing exports. However, I have been running around the theme queues and submitting d7 versions of various themes that I am interested in. I am not the only one doing that either. I think that is the biggest rub with a lot of people that Acquia has this view that they are the only ones doing it or can do it that makes your company such a lightning rod for criticism from the general community.
Follow Up
Yeti22: We have corrected the Drupal Myth on support to better reflect how we describe the options for support to anyone considering Drupal. http://drupalmyths.drupalgardens.com/node/256. Note that we have expended considerable effort to put the Myths together to encourage anyone not using Drupal today to move to Drupal. It's but one of our many efforts to create business for the entire ecosystem. Anyone can contribute from the Drupal Community, but few have.
Another example is the Drupal Showcase, where we show more than 1400 sites built with Drupal around the world. Anyone can submit their own sites and receive attribution. For example http://showcase.acquia.com/drupal-showcase/field-museum-0 that highlights Palantir as the builder and Manifest Digital as the designer.
In total, these efforts cost Acquia hundreds of thousands of dollars. In some cases, like the Drupal Showcase, we have removed the Acquia branding that was on the site, all in the spirit of doing the right thing for Drupal and the community. We won't always get the details right the first time, and we may disagree from time to time on specific details, but we believe that our intent is in the right place. Take me up on our offer to spend some time with us and see for yourself.
CMcIntosh: My statement intended to claim that we are the only ones offering free use and export (at least to the best of my knowledge), and of course the context is as of this moment. In other words, use the theme builder as you wish for free and export when you are finished. It's great that you have built a SaaS solution with Drupal, it's another endorsement of Drupal as a great system, as are Buzzr and SubHub. We readily acknowledge others are building SaaS solutions using Drupal, and others are building PaaS solutions for Drupal. At Acquia, we actually applaud this, as our primary goal is to make Drupal the dominant platform used to manage content. community and commerce on the web. If we as a community can achieve that, there will be tons of business for all of us.
--------------------------------------------------------------
Tom Erickson | CEO | Acquia
O: +1 617 669 0827 | M: +1 617 669 0827
53 State St
Boston, MA USA
Marketing
Oh, come on... Have you never heard of "Marketing"? How many products out there (not necessarily Drupal... anything) that are #1 or "the top" or "leading" or whatever. Does anyone ever take that seriously when a company makes a claim of themselves of being "the" anything?
Michelle
I dont think there is an
I dont think there is an issue with Acquia marketing itself, but it should be put on the same playing field on Drupal.org as any other Drupal based firm. If that is the case then i dont see any issues here. With regards to the Co-maintainer, if people are concerned that Acquia would have too much control if they supplied an employee to do this, and Acquia means what it says and wants to contribute towards this drupal 8 effort, why not donate money to the Drupal Association(Non Profit if i am correct) and they hire a co-maintainer. This way there is a level of segregation between the organization and the movement forward.
Acquia is not marketing its
Acquia is not marketing its support on Drupal.org. The original comment came from *.drupalgardens.com site, created by Acquia, unrelated to Drupal.org.
.
A co-maintainer hired by the DA wouldn't be able to do a whole lot since the DA is not allowed to influence core.
Michelle
The DA could, in theory, fund a co-maintainer
But they couldn't directly hire or manage the work of that person under their current bylaws. For that to happen, there would be three major prerequisites:
1) There would need to be a community structure to hire and manage that person;
2) The Board would need to support it in a way that was in compliance with the whole of its bylaws; and
3) The Executive Director and the Board would need to find the money to cover it.
I am not trying to say that the DA should do this now or in the future. I am just putting it out there as a possibility.
Of course, with the ongoing structural changes, the DA bylaws will change as well, but my sense is that, given the strongly voiced support for maintaining the no DA influence over core proviso, it will be carried over.
Structure of Drupal project
Agreed that this is a valuable discussion--thanks all for contributions so far.
At the very least, I think, many observers are noting a strong parallel between Dries' central placement in Drupal decision making and Acquia's increasingly central placement in the Drupal "ecosystem" and are asking: To what extent does Dries' personal control of the Drupal project affect the placement of Acquia in the project relative to other players?
Aside from those that would theoretically apply to any Drupal company its size, questions about Acquia and core come down to Dries' multiple roles in the Drupal project. These are front and centre in Acquia's presentation of itself, e.g. http://acquia.com/about-us/leadership: "Dries Buytaert is the original creator and project lead for the Drupal open source web publishing and collaboration platform. Buytaert serves as president of the Drupal Association, a non-profit organization formed to help Drupal flourish. He is also co-founder and chief technology officer of Acquia...."
So in important ways the questions here are not really about Acquia--they're about the Drupal project itself.
It's probably accurate to say that the Drupal project falls now into three domains:
How well does the current structure of the Drupal project continue to serve and ensure the long-term health of the project? To the extent that we're identifying issues, our challenge looks to me like: how we we strengthen both the Drupal community and the Drupal Association in ways that make the project increasingly stand on its own, drawing on diverse contributors but not dependent on the personal role and decisions of an individual founder.
This thread is super
This thread is super long!
Being a community member before an Acquian, I'm always dealing with this argument. I don't want to write some epic essay on it since it gets tiring, but here's a few things I believe:
Drupal is now a "big thing" that employs everyone on this thread, and most of us very well. This is in a large part because of the role Acquia plays in making Drupal acceptable for enterprises. It's also people (like myself) who did big gigs in the 2005-2008 era, but it's primarily Acquia. This isn't about tech, it's about appearance in the market. Yay! This is a GoodThing IMO.
I could quit my Acquia job and probably make 1.5x or maybe even 2.x the money doing site builds for big clients and high end direct consulting. The market is that good IMO. I work for Acquia because it is a tech company and we do interesting stuff and I work with a goddamn brain trust. I love that. I don't feel stifled from contributing or working on growing the community, quite the opposite.
We're all doing well. The opposite is a much worse problem. Acquia is not forcing core developers to stop hacking core in their "spare" time. The honest truth is, getting paid and being able to quit at a reasonable hour is a nice thing. I know many people w/o families in their early 20s think I'm crazy (I did at the time), but it's pretty sweet.
The Gardens team does 90% contributed stuff anyway, but internally David, Peter, Gabor, Katherine, Myself, Alex, etc all clamor for more "free" community contrib time and do have arguments w/ management about it. However, the big decrease you may have seen from these people is more to do with them just having full time jobs and families and not wanting to participate in long ass issue queues all night as much. I think that's okay. I don't think any company gives its devs more free time to contrib on the company dime than Acquia. So I'm just saying, it's not Acquia, it's having a full time job which is the problem here and it shouldn't be a problem. We should accomodate that.
As a solution, I propose we focus on mentorship arrangements and training so we can grow more core devs. Chx I know is working on this. Also, the decision making, communication and collaboration models on d.o. don't work well anymore and they require way too much investment to be involved + it's frustrating.
I think those are the real problems worth solving
Some of my thoughts on Acquia's influence
I'm glad that this was brought up and that we can have a constructive conversation about it.
I posted some of my thoughts about Acquia's influence over on my blog at http://buytaert.net/does-acquia-suck-up-all-the-drupal-talent.
Thank You
+1, I am very happy to see that you (Dries) out here on G.D.O. and D.O. showing your support! Please respond more often!
--Sig--
Owner of Proper Programming, LLC a software and website development firm.
Partial Answers
@Dries, thanks for writing that post, and for commenting here, but I was curious if you could address the other concerns that people have. Earlier in this thread, @effulgensia wrote an excellent breakdown of seven distinct concerns raised, and I added an eighth issue in a reply to that comment. After reading through your posts I see you addressing issues 1 & 2, but the final six haven't been addressed at all.
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Is there any way to
UPDATE: Nevermind. Found it.
Is there any way to unsubscribe from notifications to this discussion? I think this was a fruitful conversation, but it has gotten way out of hand and I cant handle the clogging of my inbox.
We stopped contributing code for exact same reasons
I just came back with my team from doing a 2 days Drupal workshop to 75 DDIT Students in Nadiad, India.
Up until 2008, I had tasked my Drupal Developers working on our payroll to work with community and see if they can contribute code and actively participate in Product Development. 20% of time of our developers was to be put for Drupal Marketing, Promotion and Contributing code. We did organized First Drupal Camp in India http://drupalcamp08.drupalindia.in/ and sponsored the 2nd one in Pune.
But exactly for these reasons we decided stay at arms length with contributing code and stopped any future contributions - http://www.gloscon.com/blogs/roshan/dropping-support-for-our-drupal-cont...
At this moment, my entire Drupal team is being cross trained in Ruby on Rails 3.1 and we are slowly transitioning our company to do more RoR and Android Development.
You cant event keep your site
The modules you listed had very little usage, one of the pages did not exist, and other module has a security alert from the security team. None of this is a Drupal issue, more of a poor planning and implementation on your part.
I would recommend first researching use trends and building that.
Thank You
Thank you Chris. You may want to fix your site that is currently giving 404 error.
I just wanted to present a point about why a certain decision is taken that may help. The reason this thread exists is because certain people have concerns how things have shaped out in Drupal over last few years. I just added what we felt. Everyone who has given free time over the years to Drupal ecosystem has right to present the point.
2008 trends are different from trends today. I like HTML5, CSS3, RoR 3.1, Android more compared to Drupal. Others may have different interest.
probably should fix that
probably should fix that site, its not a primary business model, but what I meant to say having done a contrib module. I learned that I should contribute back things that are already part of what I am doing not specifically go out of the way to contribute something. So say I am looking to use a balance tracking module for users on several sites, I would probably contribute something like that(http://drupal.org/project/balance_tracker awesome work on that one), or like what i did with Aegir and Services api, http://drupal.org/project/hostmaster_plus i have a vested interested in seeing that work. Granted for last couple of months i have been too busy to work on it, but still its something i am in to.
You mention HTML5, RoR, and Android as a part of your interests / business model. There are projects related to those within drupal and that would probably return more for you than something that just put out to put out there.
and again you mention your
and again you mention your Trends and i was speaking of market trends. Of course they change from year to year(more like day to day), but thats part of being a competitive company is knowing what your market wants. That definition may change for you also, but Aquia has little to do on one company or individual's market(other than maybe show them a niche that is being created).
Some thoughts
Some thoughts re: http://buytaert.net/does-acquia-suck-up-all-the-drupal-talent
I really appreciate this fact and think the community is thankful. However, everything has a root or seed. Traced to routes (or the seed) this originates from the fact that Drupal was helped by so many volunteers and netizens who tested and tried it, ran it, and contributed in the form of issues and other posts for free, and a collective amount of enormous time was given which could have caused a company a big fortune if they had to pay for it. Had they not done so in the beginning and through the middle, this money will not be eventually coming to the "my shares". Its just another way of looking at things and acknowledging. Some may even feel put off by the word "my" as they feel Drupal is something public and not a private property. This does not in any way hint that they mean to "own" any contributor or is snarky towards them just because they got a fat job. Its just a feeling of "divide" that widens when not just some mid or small sized companies are in the eco system but someone so large as Acquia is there which even purchases/acquires multiple other Drupal companies.
IMHO saying something like "I also think there is also a fair share of FUD (fear, uncertainty and doubt) being spread." is not in much good taste - people having different or even opposing viewpoint are saying something out of love and passion, and the counter arguments are not FUD, if something is not in line with your opinion that is not FUD. It really leaves a bad taste in the mouth.
Probably because there is no incentive. Incentive can be in cash or kind or even some good words or even recognizing "ideas" prominently (see http://brainstorm.ubuntu.com/ or http://wordpress.org/extend/ideas/). Also some people may think if they do contribute a new and noble module, this will be ultimately in the Acquia distro of the Acquia, the company which will make money ultimately but they, as the module creator, won't get a penny for the module. In the past when everything was free and there was no huge exclusively-Drupal company as Acquia (which initially started on one premise but later expanded that to include all aspects of Drupal business) there possibly could not be such feeling of being deprived. Times have changed from a time when contribs were mostly free, maybe with some few companies paying for devs, to a time now which breathes commercialization and money in a huge scale.
Its really not possible in the way when Drupal versions one or two were created. Probably big companies like Acquia or others can pay to create such a module that would have been created for free at the time of Drupal's birth. But it is all "can" and "maybe". Not something that is going to happen. Drupals modularity was the most valued thing http://drupal.org/node/662 and still many people use just because some other module's are not there in other cmses. And modules like CCK, Views, OG which actually makes Drupal unique among other cms-es and has been one of the main reasons of mass adoption were created much before Acquia. And there are no signs that Drupal is going to have anything new that actually makes something new for the end-users (the actual site visitors for whom the site is). Unless some very young grad or student again comes up with something called innovation, essentially not born out of money but some "other" inner urge.
Using name Drupal in company
@Dries - pls refer to your post http://groups.drupal.org/node/15023#comment-50571
Now we have DrupalConnect with "Drupal" in company name and you have no objection there?
You wanted to call Acquia Distribution "Carbon" and not use "Drupal" word in it when coming out of Acquia. http://groups.drupal.org/node/15023#comment-50678
And today we have DrupalGardens.com
So rules can be changed anytime - right - or is it because one company is Acquia partner and second domain is Acquia product, these exceptions are ok?
Roshan
.
This really isn't a "Bash Dries and Acquia for every perceived injustice thread"...
As for your specific point, I don't see an issue with Drupal Gardens as the "Gardens" is adding something distinctive. If it were "Drupal Build-a-Site" then that would be too generic. But "Gardens" isn't something many people might want to name their product or something that implies it is the only one of its kind in an area where many offer similar things.
Michelle
are the following names okay then
Just saying, and I do not know details, neither I am supporting or contradicting anyone ........... so are the following names okay then :
drupaloasis
drupalbackyard
drupalconservatory
drupalgreenhouse
drupalnursery
drupalpatio
drupalterrace
Are there any issues with these names if there is no issue with drupalgardens, well, just sayin, no offence please,
These names would be OK per
These names would be OK per the Drupal trademark policy.
Please see the Drupal
Please see the Drupal Trademark policy at http://drupal.com/trademark - I think this should answer most of your questions. I am pretty sure that it doesn't say that you can never use "Drupal" in any product/company/domain names (the thread you link to is just discussion, not the policy), just that on some cases they need application and approval (generally for-profit uses).
commercial use is also possible in some cases
Some forms of commercial use is also possible but than you'll need to apply for a license and pay for it. But follow Owen's advise, read the policy :)
--
Check out more of my writing on our blog and my Twitter account.
All procedures followed for the Drupal Connect name
This isn't the first time our name has been questioned (greggles raised the issue a couple of different times), but per the trademark policy, we have paid the appropriate fees and obtained the appropriate permissions to use Drupal in our name.
Steve Edwards
Drupal Connect
I might be mistaken, but
I might be mistaken, but didn't you also have to change your name? (I know you changed your name, and heard through the grapevine that it had to do with the TM, but you know how that goes...)
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
You are mistaken
I'm not sure I understand, but I think you are mistaken. As I stated, we went through the appropriate machinations to use Drupal as part of our name. Why would we have to change it if we got permission to use Drupal in our name?
Drupal Staffing -> Drupal Connect
I understand, and I'm actually trying to help you make your point. I think that the issue was that "Drupal Staffing" could confuse people into thinking that you all were the "official" staffing agency for Drupal, while Drupal Connect doesn't cause such confusion. Like I said, I could be wrong, but either way the point is that this doesn't sound like a case of abuse of the TM policy at all.
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Name change had nothing to do with trademark policy
Actually, the name change had nothing to do with the trademark policy and everything to do with our purpose. My boss started Drupal Staffing before the trademark policy was ever put into place, and at the time was focused solely on finding developers for shops that needed them. However, as time went on, and the demand for development increased, they moved into development and away from staffing, hence the need to move away from the Drupal Staffing name. In the interim, the trademark policy had been implemented, and we merely complied with the requirements as we changed to the new name.
Thanks for the clarification...
wasn't trying to say anything negative about the change, but your old name was almost certainly not allowed under the trademark:
Drupal + Staffing would easily cause confusion amongst people looking for Drupal staffing services. Anyway, it's a moot subject at this point, and you went through the process with your new name and were approved. Incidentally, does anyone know where we can see the process in action?
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology