The Developers MUST Be Stopped!
blackhalobender - March 30, 2007 - 15:41
The developers must be stopped! 5.x isn't even properly documented and they are already programming 6.x? What is going on? The forums are clogged with unanswered questions. The handbooks are not accurate and span multiple versions. Slow down guys/gals! It's not a race.
:)
don't agree
go on with your fantastic work :)
Agreed
As for slowing down? Isn't Drupal already doing that?
The last two releases have had the longest development/testing/stabilisation times of any Drupal releases that I've witnessed.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
Please help document
Developers develop. Some of them took 8 months off to write a whole book. Would love to have more help filling out the handbook. Anyone can help document. Thanks!
--
The future is Bryght.
the problem is
Once I have enough time and experience with a version of drupal to feel ready to contribute modules and documentation, the system changes and my contributions become useless.
From conversations I've had at conferences I've attended and spoken at in the past year or so (where I usually promote drupal as a great example of F/OSS community) I know that many users, developers and consultants agree. Also, I know many that fear raising this crit for fear of being ostracized from the community.
This is an important discussion that should be hashed out, not just dismissed.
"Once I have enough time and
"Once I have enough time and experience with a version of drupal to feel ready to contribute modules and documentation, the system changes and my contributions become useless."
Part of the problem is that the docs are not separated by versions. If they were your contributions wouldn't seem to be outdated so fast because people still do use older versions.
Good point...
People do still use older versions.
Help test the revision tags module
http://drupal.org/project/revisiontags
It could help us version the documentation so that 4.7, 5.0, 6.0 docs are all separate but related.
- Robert Douglass
-----
Lullabot | my Drupal book
Video on the revision tags module
http://www.lullabot.com/videocast/the_drupal_diff_and_revision_tags_modu...
This could help solve the problem of versioned documentation.
- Robert Douglass
-----
Lullabot | my Drupal book
Agreed. not from the point
Agreed. not from the point of view of someone who builds sites much, but more as an occasional themer and a person who is often the go-between for developers and organizations. I'm seeing lots of sites falling by the wayside that have outdated installations of Drupal – and worse, customized modules – right from the day they launch. Organizations that have multiple versions of Drupal installed for various projects and are struggling to keep them straight.
Keep developing Drupal – I love 5.1 – but please keep the pace managable for all involved. I was floored when I heard how soon 6.0 is expected. Excited, but also anxious about what else I'm going to need to relearn and rebuild. Or worse, what else is going to just fall into a state of disrepair.
the bigger picture
It is important to understand that many organizations get introduced to Free/Open Source tools via the web. On the client side, the first Free tool used is most often Firefox. On the server side, more and more, the introduction is having a site running drupal.
The frustration that organizations, who's sites aylwin describes as lingering, experience is not only directed at drupal, but towards the concept of Free Software in general.
Drupal has gained a position as a leading tool, on the forefront of people's knowledge of Free Software. As such there is a responsibility to focus on stability and long term use.
I am not saying that the developers should stop "doing things" but that they should think and be more deliberate before they "do things" and they should make more of an effort to understand the role that drupal has in the larger picture.
I think jmcclelland sums it up well, "I'd trade a stable CCK for drupal 6 any day!"
Mutually exclusive?
In a rapidly developing area, I can't see how a tool that focussed on stability and long term use would ever become (let alone stay) a leading tool.
Unless of course you define 'leading' just in terms of popularity rather than actually being a leader of where things are heading. Drupal (for whatever reason) attracted developers that on the whole are more passionate about being part of the latter group. And it was those developers and that excitement that got Drupal where it is today.
I can understand why some people want long term stability, but to be honest (in my opinion) Drupal probably isn't the platform for them.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
What if it were both?
Can't a project offer both long term stability and be a leader? Or are we doomed to continually re-write websites? If so, what is the advantage to an organization of paying someone to install and customize a CMS?
Leading
Can you think of any examples in a fast changing area?
Leading the pack means being on the forefront of change or else getting left behind. If someone wants a CMS that focusses way more on backward compatibility and API stability - they should look at something else.
To be perfectly frank - that reeks of FUD. The situation is not that bad.
I don't know - that is really up to them to figure out. If they haven't considered ongoing issues, they haven't planned very well.
I'm not a consultant and I haven't paid anyone for a Drupal site - I'm just a self taught user that has contributed a ton of forum support, has written a small handful of handbook pages, and a shared module. Before using Drupal I wasn't a PHP developer or a web designer either.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
If someone wants a CMS that
It's great to read an "old-timer" writing this - Maybe someone could repeat it on Drupal's home and download page!
It is for a growing number - By the time a user becomes somewhat acquainted with version x, up pops another one... and if you're not within 2 versions of the current major, you're on your own. So there is pressure and frankly, I can understand why there are "lingering" sites out there.
Hopefully, Profiles may provide the answer but I haven't used it to comment.
Mike
------------------------------------------------------------------------------------------
A simple thanks to those that help, a price worth paying for future wealth.
It isn't like it's hidden
http://drupal.org/node/65922
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
Agreed!
Agreed, this is a major problem, the lack of documentation or poorly organized documentation. Would it not be great to see Drupal, which already stands as a leading Open-Source project, take the lead and truly address the issue by overhauling the documentation. Think of what a solid platform this would be if all of us newbie and intermediate users could get a handle on some of the more abstract concepts, like templating with Views and CCK, etc.
It is getting to the point where I would rather just go back to building sites in XHTML and CSS, and updating them manually, than wading into the waters with some of these CMS'.
Outdated?
What is an outdated installation?
We don't even have official releases of everything for 5.x. It's bad enough having to go live with -dev versions, but I'm using at least one module that is still in HEAD. And I'm not using any exotic, I'm-the-only-one modules.
Nancy W.
now running 5 sites on Drupal so far
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in Your Database
I'm an E-Learning Designer/Developer - I'd love to help
I'm still learning everything first though. After, I will join the docs team for sure.
The problem is that it's the
The problem is that it's the developer who know stuff.
I'm registered to edit handbook pages, and when I see things that need fixing I fix them -- but I'm not a detective.
Obviously you know how to type
Most of the developers have contact forms here. Ask them for information, then edit it into something readable and understandable (even if that means some playing with it), and submit it. That helps take some load off them, makes you famous, and others happy. In most large commercial installations today it is unusual for the developer to write the docs - they have doc writers for that. But the writers have to get information from the developers.
Nancy W.
now running 5 sites on Drupal so far
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in Your Database
---
or hop into the IRC channel where you can gain advance knowledge from the devs who are reguarly online there.
Feel free to help...
If you know enough to know something's documented inaccurately, you know enough to help fix it.
Post a documentation issue, or even join the documentation team.
On the forums, help answer the questions you do know the answer to. This encourages others to do the same, and your name will get in peoples' minds as a positive contributor, making people will be more likely to help you.
But standing on the sidelines and demanding that other people do work? That'll get you ignored at best.
value the opinions of the users
Drupal is the great tool it is not only because of the developers' skill and talent but because of the people/groups that use drupal.
Even a shout from the corner of the room from a frustrated user should be valued and respected, not dismissed defensively.
see my above comment...
see my above comment...
Documentation is a funny thing. Without it - it's hard get more people trained enough on the system to be on the documentation team.
Documentation Team
Yes, there are people who have special documentation maintainer status, but ANYONE can contribute to the documentation at any time. If you have an account here, you can write. And you can comment on stuff that is already written; that becomes part of the documentation.
One of these days I'll have to find out who said it: "If you're not part of the solution, then you're part of the problem."
NO: "The docs are awful!"
YES: "I think this needs to be changed in this way. Would you like me to help do it?"
Nancy W.
now running 5 sites on Drupal so far
Drupal Cookbook (for New Drupallers)
Adding Hidden Design or How To notes in Your Database
when things move so fast
There are many people that would help with documentation, but once they have worked with one version of drupal enough experience and knowledge to feel comfortable participating in the writing of documentation that version is either no longer in use or no longer supported.
So the speed of change to the core API is preventing good documentation and preventing more people from participating in writing that documentation.
Why our docs are so crappy
"join the documentation team." Haha!
Please don't take it personal, but my application has been around for two months or so - unanswered! And mine is not the only one...
Maybe I was a little bold, but I'm not sure the doc team is really looking for helping hands...
From my POV, the Drupal handbook is really Web 1.0 or maybe 0.8. Even Linux distros have Wiki style docs, and compared to that, Drupal is easy to master. We need a Wiki, too. I don't know, why faith in the community is not strong enough for that...
Plus: I read too often on Drupal.org that people should shut up and help instead of complaining. I'm absolutely sure, there are hundreds of people out here who would love to help more but get lost in the all too chaotic structure and legacy UI of Drupal.org.
Sure, developing is fun. Hard work, but fun, as you can see real results. Writing docs or answering questions can be fun, too. But if information doesn't get properly structured to build up a knowledge base, you lose the feeling that it's worth the pain. As soon as we give people better tools, there will be 500% more involvement in docs or support.
Now you can say: Please don't complain. But is it really better to remain silent and look away? I often can understand both sides.
So please don't feel offended - it's not about you but about things we could and should do better. As soon as I have some time left, I'd love to help improving these tools to build up a great Drupal Knowledge Base. If someone wants me to help...
Pancho :)
really?
You've had doc maintainer rights for a a few weeks (karldied sent me an email about it). I evidently missed the issue you opened so it remains unclosed. I guess I should go find it to complete the circle.
My life has been somewhat busy, hectic and kind of sucked for free time this last few months but even with that, I've added 10-15 people with doc rights. Of course, it's known I and others here respond really well to sarcasm, especially in a volunteer capacity. Sarcasm is fun to experience and helps make people feel that all the work that our volunteers do is appreciated and valued and not treated with contempt. Remember sarcasm builds community and respect, well, maybe not.
As to wiki style, that handbook is pretty much wiki style all ready if you have rights. Just not wiki syntax which to my mind is good as wiki syntax is non standard markup and yet another thing to learn. The handbook is about to undergo a rather dramatic structure change as the result of the Drupalcon last week. I've mentioned I am working on the write up to the docs list already.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Okay, okay... I'm happy!
Okay, okay... I'm happy! :)
Thanks a lot for adding me to the Maintainers Role - It just went unnoticed cos the issue I filed remained open.
I think I have a pretty good idea of how much work you guys had, especially in the last weeks, so I'm just happy the general flaws are being addressed sometime in the near future.
To me wiki style I doesn't necessarily mean wiki syntax, but the "wiki philosophy" that everybody (or everybody registered) can edit anything. And pages don't "belong" to anybody but are a common effort. To me there is no doubt that this approach leads to the best documentations possible. We need that.
Have a nice weekend, Pancho
Not wiki
Wikis are good for some things, but for technical documentation I don't think they work. It's not like wikipedia where there's no clear right/wrong answer. For most things in technical docs, there is a Right Answer to many many many questions. The people answering that should be someone who has some idea of what that right answer is.
The handbooks are already kinda like that, actually. Any registered user can add a book page. Any registered user can post a comment on a book page, detailing some problem with it. Being on the Docs team (I was just added to it recently) just means that you can edit the page to incorporate those comments that are valid criticisms, and being a Site Maintainer just means (in relation to this issue anyway) that you can delete comments that have been incorporated. So it's already semi-wiki.
One could argue that there aren't enough people on the Docs team to do said comment-incorporation. Very true! That's why the Docs team keeps telling people to join the Docs team, so that there's more of them! :-)
--
Larry Garfield
http://www.garfieldtech.com/blog
I completely agree
+1 for wiki.
i sorta agree
Drupal development is a speeding train that really should be slowed down. I'm all for new features and better systems, but constant and frequent changes to the core API is going to drive away many developers and users.
Also, with each change the rate of module die-off is going to increase.
I've been trying to write up an article for a while expressing my concerns with the state of drupal developement, hopefully I'll find the time to do it soon.
It's time for drupal to mature and slow down the API changes.
Has been discussed
This HAS been discussed. "Frequent changes to the core API is going to drive away many developers and users" -- this has not proven to be the case. Developers....maybe (don't have any data, but I still see more people joining the community than leaving), users -- not so much. Depending on how you define "user" -- well, the data always gets migrated, even if the API isn't, and we strive to have a more useable application every version.
Module die off is a GOOD thing....we have almost 1000 modules, and many of them are crap.
There is a *perceived* concern that keeping up with API changes has a cost. Not changing and adding new features and improving performance and making things easier also has a cost. It's my opinion that the minimal work that needs to be done to move (for example) a custom module between versions in order to benefit from all the advances in the new version.
--
The future is Bryght.
api changes
API changes are good. Making a better system that is easier to user is good.
Making those changes every 6-9 months is bad.
...
Somehow without changing the development model in the last 6 years Drupal has continued to gain in popularity and support. I think changing tracks now would bring things to a crashing halt
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
stay the course?
I don't see this as a valid argument. It refuses to address the many issues being raised. The popularity of drupal is not at issue here, the usability of it in the long term is. not changing just because you think the current path has worked is bad logic. There comes a time when you must realize that the growth of the project and it's massive user base changes the equations.
"A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines."
--Ralph Waldo Emerson (1803–1882)
...
Well, that counterpoint is almost as old as Drupal itself is. As Drupal development relies on people 'doing things' the only course of action would be to convince those people to stop 'doing things' which isn't going to happen because difficulty in 'doing things' in the present version of Drupal is why people 'do things' to make it easier in the next version.
Feel free to look through the history and see where this has been brought up time and again and development still goes forward, change happens and in general improvements get made for each advancing area.
Primarily because it's easier and faster to do more with the newer versions of Drupal. You do not have to upgrade as long as you are using a Drupal version that has released security fixes for it.
so my thoughts on
is that "I don't see this as a valid argument." especially considering it hasn't been for 6 years and that very approach is how we got here and seen as one of our major strengths. Your opinion and experience may vary but that's all right too.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
please
please respond to the other comments on this post and address the issues being raised.
Do you not recognize that what might work for a new and young project is not good for an older and more mature project with a massive user base?
The reality of drupal's user base and community have changed in the past 6 years. the process and methodology should change over time as well.
..
There are no new points raised in this thread that hasn't been raised and answered in any previous discussion. We are always growing and who says we're done yet? We still have a ways to go before we're the kitchen sink CMS. Already we are soon to be equaled in many other CMS products out there. If we slow down, we will be trampled.
Drupal processes have changed over time to accommodate some of the issues. Most of these changes are still occurring and maturing and have an impact, just evidently not a satisfactory one for you. These things take time and the developers outnumber the rest of us. With the new educated talent coming out of the Drupal-Dojo project I have hopes that we will have a new influx of people willing to help out.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
_____ vs. growth
Again, I don't think anyone's against growing Drupal and growing its community base. I don't know the CMS playing field so I can't speak to the concern about Drupal being trampled, but I do know that just as Drupal risks losing out by not adding enough features, it also risks losing out by adding features that either function poorly or that users don't (or can't) use.
I appreciate the work that Drupallers have done in, as you say, changing process to accomodate some of these issues. I hope that work continues.
There are no new points
I'm sorry, but you are being utterly dismissive of people who are interested in the direction of the project now, not a year ago, not six. If you are so confident in this position, defend it! If you know the points that were valid before, what makes them less valid now? What prevents you from restating them here?
You cannot hold it against people that they were not around for these discussions. They have a right to voice their concerns. There is no Drupal elite, and if there is, I want no part of it. People are raising a serious discussion, and if it wasn't this thread wouldn't be so active.
Is kitchen sink our real goal? So what if we are equaled or passed in some capacities by other OSS CMS's? This isn't a competition, we don't need to end up on top. This isn't about market share, this is about the community of Drupal users, I'll leave cornering markets to Microsoft and other proprietary vendors.
Sepeck, I have spoken with you many times in #drupal-support and have always found you to be rather helpful and friendly, however in this thread you are being dismissive and adversarial. I want to hear what you think, so state it, don't brush off my and other's valid questions and concerns about the project now and in the future.
arg
I am not being 'dismissive' of people. Please don't attack me as if I said anything like that. This is a threaded forum so I answer the question presented and then someone tries to justify/clarify their original post with something that to my mind is not related. Just because I disagree with you or someone does NOT make me hostile or dismissive but accusing me of such does irritate the hell out of me.
I am saying as others have that so far no one has said anything new. Or proposed anything different. I am not going to do all your research for you as I simply don't have the time. I have mentioned these threads exist. If you or others want something to change, then you need to present something that is different then 'we must slow things down' because past experience has shown that's not going to happen. So far, this is a repeated discussion. This is NOT hostile, this is information for you and others to understand.
As to goals? Watch Dries' presentation from OSCMS2007 when it gets put up and linked. There is lots to be done that are areas we are weak or difficult in particularly around file and image handling, leveraging web services and such. We're barely in the kitchen at this point.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
hmmmm
So you say that you are not dismissing anyone, that you are not refusing to discuss the issues people are raising around the idea that changes to the core API of drupal should slow down (in the interest of the longterm health of the project), and then you simply dismiss everyone by stating "that is not going to happen" as if it is a fact given from god.
The pace of change of the Core API will only slow down if enough people make enough solid arguments for it slowing down and that discussion is not simply pushed off.
I understand that you are not willing to discuss the issue, I refuse to believe that the entire drupal development community is equally as stubborn.
I have read the other threads, I have seen this discussion pushed off *every time* by a few people with the same "we've discussed this before" line. I have to say that you have been more respectful than others have in those discussions, much better than the "if you dare to discuss this I'll ban you from the site" attitude some other core developers have taken in the past, but you still are being dismissive.
The drupal community has grown and changed and it might once again be time to have this debate in a productive and non-dismissive way.
If you are saying that for the next couple of versions of drupal the api change will happen fast, but the goal is to get to a stable point and slow down api changes at some point to every couple of years, while new features and fixes are added to the then current version, that is one thing. To think that a project like drupal can continue forever at this pace is another.
I'm asking this out of genuine interest, which of those are you arguing for?
I'm not trying to attack
I'm not trying to attack you. Sorry if it came across that way. This is obviously something we all feel strongly about.
This really isn't about proposing something that's new and different. Its about rehashing something that is considered settled when clearly its not in the minds of those of us bringing it back up. And even if it has been settled why not reexamine if what made the speed of development useful between 4.6 and 4.7 or 4.7 and 5 still holds true now between 5 and 6. As the use of Drupal has grown, the makeup and therefore the needs of the community have changed. That is what we are discussing.
For me, this is about a democratic process where the people in the community have the right to revisit decisions made in the past and see if they are still relevant or need to be revised to meet an ever changing social ecology. There is something that doesn't have to do with software taking place in Free Software, and the Drupal community should be responsive to that. I have been involved with Drupal for a long time, between 4.3 and 4.4 when the theme system changed significantly, I thought it was needed and good. But if you look at the number of contributed themes from those days, and compare them to the number now, you can clearly see that there are a lot more theme developers. That changes the equation.
Furthermore, what I am proposing is different. I am saying that stating that this discussion has been dealt with before, and worked in the past is not sufficient right now. Its as fair a question today, as it was six years ago, and the answer will certainly be different based on what has happened in those six years. We have to look at the changing realities of the community, if Drupal is to remain a truly community driven project.
Dries' 'State of Drupal' from OSCMS2007 on google video
That video amongst a few other are already on google video...
http://video.google.com/videoplay?docid=7827250900890284668&q=drupal
a contradiction
You say that drupal process has changed over time to accommodate some of these issues. that is true and is a good thing.
Those changes have happened due to discussions like this.
Yet, you seem to want to dismiss and shut down the discussion.
There is a contradiction this that I find disturbing.
These criticisms are being made in the interest of contributing to the project. Criticisms like them have been raised in the past. Maybe it's time for another change?
Sometime issues need to be discussed over and over again, with each debate moving things closer to a common ground. Dismissing the issue by saying that these issues were "discussed" in the past is to promote ignoring the input and refusing to contemplate that it might be time for another change. I remained silent the first couple times I saw this issue debated, as I was new to the project/community back then, now I feel I have enough experience and participation under my belt to voice my opinion (or even have an opinion).
These criticisms are being made by people that love drupal and have been using drupal for a long time -- and many have done what they can to contribute back to the project. Please don't respond as if we are all hostile newbies that just don't know what we are talking about.
...
When I disagree with you I am being dismissive? Please go find those threads. I have told you they exist, you then attack me. Accuse me of things I DID NOT SAY! I explained the why. Find it disturbing all you want.
You have begun to attack me based on your ability to figure out what I 'seem' to want.
You claim I am treating you as hostile newbies? I am not. Stop attacking me by putting false words and meanings in my mouth. It is offensive and I am not going to play any longer.
You want change? Research those threads you now admit to knowing about and propose something new. I am not participating in this thread any longer. I hate being accused of things I DID NOT DO.
For the record, I 'seem' to want to help you understand. You made a one line comment that is not backed up by the historical development of the project. I answered that and then you wanted more but only said 'address the other points' without actually adding specifics so I answered you with the same answer you gave me and added some longer explanation for historical reference.
You didn't like my answer, that's fine but don't then accuse me of things I didn't do, say or mean.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
you confuse attack and debate
That is frustrating.
There seems to be no way to criticize without you calling it an attack.
...
and the other persons comment
When you personalize your justifications with direct personal critiques/interpretations, I am not playing. I answered your questions, not questioned your personal motive for this. You and the other one directly claimed I did something from some hidden motivation to stop the discussion. You attacked me on 'what you 'felt' I meant, not on what I actually said.
I would have been more then happy to help you find your way along here but when you got personal, I decided that the thread was no longer worth my time. This is why many other log time Drupal users don't respond to this kind of thread. They have less patience than I do.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
you got me wrong
I never questioned your personal motive. I was speaking to the effect your comments have on the discussion.
From my perspective, your comments seem to dismiss the points being raised.
I think that this thread has remained on-topic and respectful throughout.
There is a line between debate and attack; between criticism and accusation. I guess you and I see that line differently.
The passion you see in my comments (maybe the others as well) come from a feeling that a project that I have committed to, promoted, volunteered my time to train many people and organizations in the use of, contributed back to in the ways I can, is moving in a dangerous direction.
This comes from over 18 years of professional technology work; from seeing many hot tools and technologies that should have stayed around for longer, fall apart or die.
Drupal's popularity changes many things, the size of the community and installed userbase must be factored in to development decisions.
When I have done presentations on the history of Free and Open Source Software, I tell people that healthy F/OSS project respects the input of users of all levels, and values participation and criticism from the overall community that surrounds a project. I also tend to use drupal as an example of a project and community that does this all right.
So, my comments should not be taken as telling developers what to do or not do. this is simply me participating in the community and trying to add my experience to the mix and give back to the community.
This is a community, not a company
Even if sepeck in fact is "dismissive" of your assertions (and I don't believe that he is being dismissive), that is his right as a member of this community ... just as you dismiss out of hand the very development process and pace that has brought Drupal to this point.
Personally I feel Drupal 5 was a year later than it "should" have been. It wasn't. Why? Because development of Drupal in fact is slow and methodical. The changes we're going to see in Drupal 6 were planned when Drupal 4.6 or 4.7 were the latest official releases. And yet Drupal manages to keep up at the front of the pack of CMSs, now competing with proprietary systems. It still has more ground to cover, and for me it couldn't come fast enough.
And I write this not just as a web designer/developer but as the owner of a number of sites running older versions of Drupal.
This is an open community. You are welcome to join in and build some karma here and try persuading others to buy into your view. You are also legally entitled to take your own fork of Drupal, slow down or even stop api changes altogether, and build a community around that and maintain it yourself. That's what GPL is all about.
But simply making assertions that "things have changed" and therefore suddenly Drupal is on the wrong track is not going to persuade many of those who've benefited from participating in such a vibrant community that has built and continues to improve such a first-rate CMS. Open Source projects evolve. I have yet to see proof that Drupal has now become good enough and we should slow down and smell the roses.
I will close by asking you not to claim that now I am being dismissive of you personally. I am rejecting your arguments so far, so from me the suggestion made in this thread get a -1 from this one person.
Laura
_____ ____ ___ __ _ _
design, snap, blog
thanks
I understand the points you are making, and appreciate your perspective.
I agree that drupal is a great CMS, the issue is that such a rapid pace of change to the core API makes it less and less of a stable and usable development platform for those that are looking for something beyond the basic CMS.
I don't think that I'm saying that suddenly things have changed, I'm only saying that things have changed, slowly over time, and that those changes should be thought about during development.
When a project grows to the point drupal has, and has such a large user base ,development should happen differently than when it was a new tool.
I guess I'll have to start looking at drupal only as a CMS and start to search out other code bases and communities for the more complex projects I take on. That's just how things go, I found drupal 4 years ago when other tools I was using had become no longer usable in a number of contexts.
It just takes far too long to get familiar enough with the core API of any system. If you worked, like I do, on projects that tend have a development time of over a year, you might see my point more clearly.
I think a large part of the user base of drupal is being left behind by the pace of change. I hear these complaints frequently from people at the conferences I have attended and presented at in the past couple of years. I feel it is my responsibility to the community to pass those complaints along and advocate for those people's position.
At some point, even if that point is not now, the pace of change has to slow down.
I'm more than willing to accept some of the arguments that say now is not the time for the pace to slow down, I just can't see the logic of the arguments that suggest that the pace will never and can never be slowed.
More thoughts
We've got 2 year old projects of 100s of sites that started on 4.6. We'll be doing the transition to 5 in a couple of months. For new functionality, our strategy tends to be to work on the newest version and then backport, thus benefiting in both directions.
Interesting. Not what we're hearing from conferences *we're* attending, Eric. Again: why do they have to upgrade? If what they have works for them, why would they feel left behind? The *only* force for upgrading tends to be security / maintenance releases. A 2 year cycle for moving to the next version as it is no longer maintained doesn't seem unreasonable. A bit of insight into the "persona" of these people would be great.
Eric: as I said earlier, I "hear" the frustration/passion in your words, but other than "it seems too fast" I'm not hearing a lot of articulation on what is at issue. Data can be migrated between versions fairly painlessly, as can themes. Any non-core modules you select NEED to be selected with a long term view for long term projects....that's just a fact, in any system. If you are doing a lot of non-generalized custom development that you aren't contributing back (i.e. you carry the load of updating it yourself), then that has to be planned and budgeted for *IF* people need to upgrade.
--
The future is Bryght.
different audience
I think the reason we are hearing different things at conferences is that you are attending technical-targeted conferences and I tend to speak on Free/Open Source to non-technical audiences (librarians, public-access media groups, activists). I end up dealing with the end-users and in-house tech people that have to maintain drupal sites after their consultants have set them up, not the techies and consultants.
As I said earlier, I often advocate people stay one step behind the development curve and leap over versions as you describe, most of my 4.7 sites will stay 4.7 until drupal 6 is out, I'm upgrading my 4.6 sites now to 5.
The groups that can afford to hire us as consultants or that we can afford to donate our time to have fewer of these problems.
When I build a large project that allows me to get deep into the inner workings of drupal, I find it frustrating when that knowledge becomes useless. It hampers my ability to contribute back as much as I would like to in terms of code and documentation.
I also end up handling the projects of small organizations with very limited resources, that might also be a reason you and I are hearing different things from the folks we're talking to.
Most often when I hear "oh, drupal? yeah, we worked with that and it sucks" the underlying reason is that people's expectations were not in-line with the reality of what is necessary to maintain their site in the long term. Some of that is due to bad consulting, some of that is due to things getting over-hyped and some of that is because things change so fast.
And some of it is because
Drupal isn't quite there yet.
Slowing down isn't going to make Drupal more usable. Slowing down isn't going to make Drupal easier to customize. Slowing down would just put off the kinds of improvements that will make Drupal that much better and more usable so that it doesn't "suck."
imho
Laura
_____ ____ ___ __ _ _
design, snap, blog
slowing down vs slowing down core api changes
slowing down core api changes and focusing on the missing parts and holes will make drupal more usable; will not break complex customizations; will make the tool more stable in the long term and make is more usable so it doesn't "suck"
Do you not see how reducing the statement "slow down changes to the core api" to "slowing down developement as a whole" is somewhat a distortion of what is being said?
This is a debate about how to improve drupal -- how to move forward, not a debate about whether or not to move forward.
Please try to respond to the issues raised, do not reduce the debate to easily dismissed strawmen.
I will try to be clearer then
This is the assertion that I find questionable. The improvements from version to version do address the problems of the previous versions. The API changes are how the most fundamental problems are addressed. API changes are essential to Drupal's continued growth. Slowing down the API changes slows down that growth.
Example: If development were slowed way down and we were still on Drupal 4.6 now, we would not see but a fraction of the popularity of Drupal we see now. We would not see major corporations using Drupal like they are now. We would not see Drupal mentioned in the same breath as proprietary enterprise-level CMSs.
Many people here are conflating problems in contributed modules with problems in core. The problems with contributed modules are typically addressed in those modules, not in core. And yet sometimes the core improvements make it easier to improve contributed modules. Witness how Drupal 5 opened up all sorts of possibilities. CCK's refactoring and partial integration into core has made that set of modules much more powerful and flexible in ways that just are not possible in Drupal 4.7's API.
What I still don't understand is how slowing down API changes will help anyone -- even the people who don't want to keep up with a rapid-paced software development project. If you want more support for older releases, then that's a different issue than slowing down API changes. And you're not going to force people to scratch a different itch than the itch they've got.
People's attention goes to what interests them. Just because your interest is elsewhere doesn't make them wrong, does it?
If you're saying you want to compel developers to work on stuff that doesn't interest them, then I'd say you don't understand open source development. If you are not saying you want to compel developers to work on stuff that doesn't interest them, then I really don't know what it is you're trying to assert. Sorry.
Laura
_____ ____ ___ __ _ _
design, snap, blog
I think you are right when
I think you are right when you say I'm not providing enough solid detail for this debate.
Once I get a few projects off my plate, I'll have the time to write up details and specific case studies to illustrate the problems that people have brought up with me.
I'll let you know when I am done with that and hopefully we can continue this then.
More Than Enough Already
Eric: You (and others), have more than adequately made the point, exhaustively - All sides know what is being asked, and the reasons why - that was established early on. You are now just banging your head against the entrenched walls of those near, or at the top of, the organisational pyramid.
Yesterday, I watched Dries' "State of Drupal" address. He stated that he was keen to have as many users as possible upgrade. It's clear from just reading this thread that there is little comfort for those urging a period of consolidation.
Now Drupal has, seemingly, hit a point of critical mass, I suspect this topic will be revisited going forward by a growing army of new users adopting v5 for the first time.
I applaud your tenacity but you are better off spending your time more productively... just my tuppence, it is your time afterall.
Mike
------------------------------------------------------------------------------------------
A simple thanks to those that help, a price worth paying for future wealth.
There are no new points
Doesn't that tell you something!
Mike
------------------------------------------------------------------------------------------
A simple thanks to those that help, a price worth paying for future wealth.
But what about the existing user base?
I don't think anyone is arguing that progressive releases of Drupal aren't getting better and better. Nor do I think anyone's seriously arguing that people should stop 'doing things.' I think people are frustrated by the pace of change and how it's making their lives difficult. Yes, the userbase is growing. Yes, people continue to adopting Drupal. It's great.
The problem is that it overlooks those who now have Drupal installed. Many have put a lot of work into making it work for them, but as releases get churned out at a ferocious pace, they won't have the tools or support to continue using Drupal. People want to stay up to date. They have to – this is the internet we're talking about. But if it's too onerous to stay up to date, they'll look elsewhere.
So to say that "[y]ou do not have to upgrade as long as you are using a Drupal version that has released security fixes for it" seems to dismiss those who would like to stay up to date and keep using Drupal and keep contributing to this community, but may not have the resources/technical knowledge/etc.
Clearly, all the contributions that go into making Drupal the fantastic platform that it is are appreciated. I think what I'm hearing is that clients and people who install Drupal for clients are feeling a bit left behind by how people are 'doing things'. As a client and a sometimes-builder I know I see that risk, and I'd like to see that those who are shaping Drupal are conscientious of that. I'd like to see ways of helping make that happen, too.
maintainance
The 4.7 release has a dedicated maintainer. If people want to see it continue to be supported,then someone who is interested is going to have to work with that maintainer on bug fixes, patches, testing and security concerns. Without people who want this release to continue to be supported, then it will not be.
Drupal to download costs you nothing. However, the actual cost is implementation, maintenance and involvement with the community. If you want/need something, then someone needs to be involved to make sure it continues to exist and be supported. Open Source software doesn't really in the end cost less, it costs different and many people don't anticipate those as maintenance costs long term.
For instance, I have an investment in keeping my sites up, so I pay attention to the modules and methods around that functionality that I need. I test, provide feedback and am aware of migration paths. Without my participation, the developers I don't pay really have no incentive to help me (they don't really have one anyway but participation garners more positive feedback so more likely to have them do something). If I really needed something, then I'd figure out a way to fund it and get it done.
What you end up with though is not a cookie cutter solution that gets close to what you want but resembles everyone else, instead you can end up with a solution that is yours and does what you want. I need to dig out some spare time to write this stuff out as a white paper.
Here's some excellent posts on the subject in the meantime.
http://pingv.com/blog/laura/200702/how-to-use-open-source-and-how-not-to
http://www.lullabot.com/articles/best_practices_in_open_source_developme...
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Thanks
I appreciate your pointing me to the 4.7 maintainer and the blog posts.
From what I see in the posts to which you refer, one of the main responsibilities of the OSS adopter is to not hack the core. I know well enough not to do this – I know I'm responsible for my part of the equation when it comes to making sure it's easy to upgrade Drupal.
I guess the part that becomes difficult is the modules, where as an adopter of Drupal I have some level of expectation that I can modify these according to my needs. That insulation between what I can modify (the modules) and what I can't (core) is what makes this whole thing work. If I'm not mistaken, that's the API, and that's the part that is changing so rapidly that site builders are getting lost. Those are the folks that I usually depend on, so that's why I'm concerned.
I'm happy to not change core for my needs. But when the API keeps changing, it's pretty hard to see how the advantages of an open source CMS applies to me.
Not exactly
I'm just churning through this thread for the first time, but your comment stood out to me:
You *shouldn't* be altering ANY modules. That has some qualifications. One of the key concepts in all drupal is extensibility. There is a way to change almost everything from outside of a module. If there isn't, there should be. So, if you find something, even in a contributed module that you think needs to be changed, think about a way to do it extensibly (perhaps with its own hook?) and then contribute that patch, AND write a new module for your own purposes.
CCK formatters are a perfect example of this (and I'm teaching a lesson at the dojo on them this Sunday). Whenever you write a new field type for CCK, such as phone.module, you can write Formatters. i.e. Do I want my phone number to be 1-212-555-1234 or 1.212.555.1234 Well, what if your preferred style isn't there? You can write a module, that phone.module will invoke to add a third formatter to that list.
There are MANY contrib module sthat don't get this, and they could use a patch to make it clear I'm certain. But try not to hack even contrib, unless its a hack to make it more extensible - and then submit the patch.
OTHER than that, there also seems to be some general confusion in this thread as to what an API is. API's are just structured ways to write code - any API change to Drupal will save countless hours in the end, FOR EVERYONE. FormsAPI is a great example. yes, it broke a ton of things in Drupal and caused a hell of a long beta stage... but it also makes Drupal a very secure platform - and how many manhours across the internet have been saved from XSS attacks? Yeah, it was good it came out sooner than later.
Sam Tresler
http://www.treslerdesigns.com
-------------------------------------
"A list of common problems and their solutions can be found in the Troubleshooting FAQ."
Well...
... that's just the "Drupal way", pretty much like Fedora does it!
Sure, slower or more legacy-oriented development may also have its advantages, but who wants Drupal to be coded like the Nukes or fat like Typo3? Or - to stick with the Linux distro comparison - who runs Debian on his notebook?
Drupal 6 is going to be the killer CMS. And nothing should stop our great coders from making it stronger, faster, mightier and better!
I don't think, we will always see that big API changes from one version to the next. I think with Drupal 7, maybe 8, some 90% of the APIs will be perfect, and I mean perfect.Then we'll probably see a stronger orientation to new features and a bunch of "Golden" and "Platinum" contribs :)
Looking forward, Pancho
Drupal's definition of community?
It shows for whom Drupal developers are developing : not a community of bootstrapping entrepreneurs. It's for organizations who have the money to clean up the usability mess and patch up the holes created by all the unattended bugs or organizations with software developers in their core web development teams.
In the end the Drupal software developers are only developing for other software developers.
Scratch your own itch.
In a way, you're right. Developers are developing new features because it is something they want/need, or someone else is paying them to do. When they are finished, they contribute their new features back to the community.
This is the nature of Open Source software development. I have a feeling that many of the complaints in this thread stem from the lack of understanding of this process (I am making no assumptions about your knowledge of the process). Drupal is NOT free, you still "pay" to use it. But instead of paying with money*, you pay with your time investment in learning how things are done, updating sites, and worrying if a module will be updated for the next version. That is the "fee" you pay to use it, whether you realize it or not.
Drupal as whole benefits when you "pay" it by contributing documentation, support, feedback from testing, reviewing patches, submitting patches, and contributing modules. This is how things get better.
* Or you pay a consultant or another company to take care of these details for you.
Bingo
Nail, head, hit.
I'm just wondering: Who should Drupal developers be developing for? Who pays their bills?
Every module I've developed for Drupal has been motivated by *my* own needs, with an eye towards some level of flexibility/tweakability for other people if and when I release them to the community... and hey! What do you know? I've released a few to the community, and some people actually use and like them. That's how I contribute back to the Drupal effort, because that's what I know how to do. (I could write docs, but I'm really rather busy trying to bootstrap a business, so the docs have to wait).
Every hour of sweat and effort was for motivated (primarily) by my own pleasure, desire to learn, or *gasp* 'selfish', 'corporate' commercial needs. But the community still benefits. You're welcome.
I do understand the frustration that comes with the core API changes... I've experienced them firsthand, and at first, it struck me as odd, that backwards compatibility is not a major concern, but then, the more I thought about it, the more it makes sense: we do *not* want Drupal to be Windows-like, with the core development hampered by the requirement that every old module work with every new release of Drupal! I don't think we want a huge distro filled with untestable code...
Lean, mean, clean. Go for it.
Fast Core development = fewer/lower quality contributed modules
I love drupal, I love the way the direction of development is going. But I have to agree that core development is going too fast.
Maybe my situation is different than most of you, but I really use Drupal as a development platform for sites rather than cookie cutter brochure type sites. We can do great things with it, but its really gotten to the point that we are dealing with a different API for every project. And by the time we finish one project it already requires an upgrade because of these API changes.
But even outside of that, is Drupal's wonderful collection of contributed modules. I love all of the fancy additional modules for CCK, but you know what? They are filled with bugs (which we as a group do report, and try to help fix) simply because CCK is a big moving target. Which I totally understand, but when so much time is spent working on newer versions, I think the number of bugs is just going to increase, or these contributed modules are just going to die off.
Drupal's strength is the massive amount of people that work on it. Massive amounts of people who aren't core maintainers spend lots of time contributing to the whole. I think we are going to lose a lot of those folks work because by the time they get their contributions polished enough to be useful, they will be at the very least a version behind.
I know that core maintainers do lots of great work and I don't want that to stop, but all I'm saying is if they slow down a little bit, there will be much more time for the rest of us to follow them and smooth out the rough edges (contrib modules that work, QA, documentation, etc....)
I agree
I agree. I think fast development leaves bugs, which annoys very much and it (bugs) also degrade reputation. I have reported a bug in aggregator with php5.2 (I might reported in wrong place ). Which didn't get fixed. I think there might be more.
There are many modules which not available or are in beta stage. Which is a major issue for people for upgrading to 5.x.
I think bug fixing and porting of module must be high priority than new version. I think major version must be released in once in 2yrs.
--
Sharique uddin Ahmed Farooqui
IT head, Managefolio.com
S/w development head
I agree
Okay, maybe development shouldn't grind to a halt, but it's not a race! Every time drastic changes get made, a whole league of Drupal sites gets left in the dust. I've been part of so many projects where we've invested in Drupal because we've expected that with this strong of a community around it, Drupal would be an ideal platform to adopt and grow on.
However, those sites are falling behind quickly. If people have to re-build a site every time there's an upgrade and trudge through unanswered questions around abandoned modules/theme engines/distros of Drupal, they're going to start looking at other CMSes, too - possibly one that grow at a saner pace.
And speaking as a former technical writer - yes, anyone is capable of stringing words together to describe how to do something. And yes, everyone can always pitch in more. But the people who know how things work best are the developers themselves, so putting a little effort into helping users can't hurt. It gives fodder for the documenters to write from.
Yes - not a race!
Development should definitely not grind to halt! In fact, we should be encouraging everyone to contribute to the development of Drupal. I don't think the amount of development is the problem.
I do agree with the folks, though, who are questioning the direction - in other words, newer and newer features (the race) versus stabilizing what's already there. I vote for stabilizing.
We also are developing a lot of sites in Drupal, and like libkuman says, I'd trade a stable CCK for drupal 6 any day!
Core vs. Contrib
So.....all of this thread mixes up core and contrib.
CCK is a contrib module. AFAIK, it's pretty darn stable. Are you having trouble with "extra" CCK fields, that aren't part of the main CCK distribution? You have two choices: don't use it, or commit time to helping further develop it.
Re: stabilizing -- are you spending time filing issues, preparing patches, or testing patches in the queue for Drupal core? Drupal is not a "thing"...it is a living organism and you need to participate in the care and feeding of it.
Is it easy to set in place proper process (this is not technology alone, folks...) to maintain and upgrade Drupal installations over time? Nope, takes time and effort for each individual, company, or organization. What is your process for selecting a contrib module to commit to? How much time / billing from client projects do you set aside to contribute to community processes for maintaining and upgrading modules?
I hope that all of my comments in this thread have not been dismissive. Yep, it's an issue to "keep up" with Drupal. Each version now has a maintainer, and it is up to all of us to put effort in.
I had this discussion recently: what is the cost of spending a few hours upgrading a module and/or an upgrade path to a new solution per version, vs. the cost of maintaining backwards compatibility in the API layer? To you, the individual developer or small company, the former may seem more "expensive", but on a whole, I would say maintaining backwards compatibility is more expensive (Ref: see Windows).
Also: no one forces you to upgrade. Why are you upgrading? Do you balance the "cost" of upgrading vs. new features? Do you have support and maintenance contracts in place for clients that cover this cost?
Lots of discussion here, from business models to software approaches to community engagement.
--
The future is Bryght.
only indirectly I think
My concerns are with the pace of changes in the core API.
The way that reflects to many users is in contributed modules, that are written to interact with one version of the core API
As far as the why upgrade issue, I agree. I advocate that many people wait on upgrades and stay a step behind.
Some of the projects I've worked on, despite our warnings to the client, demanded modules that never got upgraded past 4.6, in this case, we've decided that it is more cost effective for us to backport security patches to the no longer supported version (and we'll wait till the client is ready for their next major phase of development to move any of it to a newer version).
For a while we were doing this for 4.5 internally, but stopped when we had finally moved all our projects to current versions. Now that we're doing the same for 4.6, we've started releasing those to the community.
We had asked Heine and Dries a while back how to best let people know we were providing these backports, but I guess due to the overload of them getting ready for OSCMS we have not yet found a time to all get together and discuss it.
Participating in this thread is one way to promote a slowing down of change to the core api, providing the backports to 4.6 will provide some support to those in the community that are also stuck (hopefully temporarily) 2 versions behind.
Backports
We also have provided backports over time. Generally, putting them in the issue tracker is a good thing, as a patch. Perhaps adding a category to the issue tracker called "backport" would be a good thing. Perhaps you could open an issue about this.
Also, you could apply to be maintainers for older versions. The trouble is, of course, that the project as a whole doesn't have resources to "officially" support anything pre-4.7, I suspect.
I would say, those early days of 4.5/4.6 were painful, esp. the 4.6 to 4.7 transition. Having also gone through that, I think I can feel the frustration/pain that is leaking through. We skipped 4.7 on our hosted service because we couldn't keep up with the massive changes and amount of contrib we had. I'm feeling very good about 5 and forwards, in part because of the install/upgrade systems that are in place.
--
The future is Bryght.
A good idea
http://drupal.org/node/132587
I've opened an issue as you suggested. Thanks.
I agree about stability, it
I agree about stability, it is important to build confidence in the user
A simple analogy, I know many are not fans of MS , but we have had 95, 98, XP and now Vista, how many corporations are still running 98? How many XP? Lots !
How many of these same corporations will jump on Vista because of all the whizz Bangs, we will see?
How many will wait years before the change?
If you had the choice, a stable product, which you have invested time and money, in training your users in, against an unknown, where you will certainly need to re-train your users at no inconsiderable cost to yourself. and you were in charge of the purse strings, you would chose stability first.
I am new to Drupal, only just moving from a HTML driven website, with no CSS, i have looked at several CMS over the last year, and Drupal won, Joomla was rejected on the basis of a Major revision was already nearing release. I am wary of moving to a product that is unstable, as my existing HTML site ranks 1st in Google for its category and has done for over 5 years, so any change is a gamble. At present I do all the work on the site myself so would rather spend the available time entering content than upgrading and patching the system. I would assume there are many others out there using Drupal for a similar purpose.
I am all for development of new ideas, but would remind that developing on an unstable base is probably not the best way to do things
Remember One step at a time, having all the whizz bangs gets you noticed, having ones that are unstable gets you noticed more for the wrong reasons
doing everything yourself also makes you fail
it's sort of a rule in a network based economies. if you try to do it yourself, all of it, you will get buried. for a lot of folks, it really won't matter how fast drupal evolves because some people are most focused than ever on providing stable builds that will be upgradeable to thousands upon thousands of users with functionality that can't really be found elsewhere for the price. how can you use drupal like this? well, some of the people on this list are the ones doing that. and the best way to stay hip is to pay people to do what they love and are passionate about so you dont have to worry about things that make you nervous or push you beyond where you want to go.
blogging tool/cms vs. development environment
I have to agree with folks asking for things to slow down.
I have often read in discussions comparing Drupal to say Joomla or Wordpress, people proudly saying "Drupal is more than a blogging tool or cms, it is a development platform."
When we move this fast, we belie that statement. We are adding features before we fix all the bugs and make sure that Drupal is stable and usable by people who are actually using it for development. We are not paying attention to the fact that many people don't have one month turn around on projects, but rather have slower thought out development processes.
I can slam together a great blog, basic community site, or brochure site in a matter of hours. I cannot spend a month or two learning a new API, spend weeks in meetings understanding how an organization does their work, spend weeks trying figure out how to bend drupal around their workflow, spend weeks building that, spend weeks testing that, spend weeks training them, and finally deploy it fast enough to use what I have learned again on a project of that scale in the same Drupal versions.
It took me months to get comfortable in 4.7, I haven't really tried 5 professionally because I (and my company) can't afford to spend the time learning all the differences between versions, because we have to spend our time building stable mature systems, and because we all took months to learn a new api when 4.7 came out. Also many of the modules that we need have not been upgraded; so its stick with 4.7 or upgrade someone else's module which is expensive when you charge by the hour.
If PHP changed what its core functions did as rapidly as Drupal does, Drupal and every other PHP based project would grind to a halt, or everyone would pick a version of PHP and stick with it, or just not use PHP. That is my fear with Drupal. If I wrote a Perl or PHP script 5 years ago, and tried to use it with a new version of either, chances are that over 5 years lots to most of the functions I used would still work. I can't use a module I wrote last year with current Drupal. I will concede that this may not be a 100% fair comparison, but it highlights a key difference in OSS projects that are being developed so that other developers can learn it and develop in it, and a whizbang feature-rich blogging tool.
If that's the direction people want Drupal to move that is fine, but we can't pretend that it is something that it is not. As someone who has done development with Drupal since 4.3, and really likes it, I would like to see more interest in keeping stable for developers doing things that are outside the box of blogging and CMS, and truly a dev platform for cool complex projects that make use of Drupal.
My original comment +
My original comment + experience + eloquence = your comment
Very nicely put
I think this comment sums up the general comments very well. Linux, PHP, and many other Open Source Projects remain popular because experience on one version can carry over to the next version. When a new version of Fedora comes out, we don't have to update all the software we have running on our systems, but when a new version of Drupal comes out, all the modules have to be updated in order for our sites to work.
And I have to say that this DOES break content! I had a site that used the Reviews module, but when I upgraded to 5.0, that content didn't work any longer. Also, my Taxomony Context pages didn't work either until recently when the module was finally updated. And all the content that contains Go module links are useless until that module is updated.
So yes, Drupal upgrades DO break content.
Of course, now that I know that, and now that the CCK module is part of core, I can rebuild my reviews in CCK nodes and be fairly confident that they will continue to be accessible to my visitors through future upgrades. Not sure how to deal with the Go links, though. Maybe just depend on an outside link tracking script.
Overall, I love Drupal. I've tried several other CMS tools before and know on a gut level that Drupal is a much better way to go. I'm hooked. But if I can't depend on the contributed modules staying current, and if I need them to have a working site, then I have to give up on the idea of ever upgrading, which kind of defeats the purpose, doesn't it?
- Alan Tutt
http://www.PowerKeysPub.com
BRAVO!
(((( STANDING OVATION ))))
Especially for this :
because it's happening right now.
Drupal is a dream for people who have software developers in their teams. If you need to subcontract to clean up it's bugs and/or usability issues, it can become quite costly.
Contribute back?
You are, of course, working with those subcontractors to contribute fixes for these bugs and/or usability issues?
--
The future is Bryght.
If PHP changed what its
To be blunt, the reason PHP is one of the crappier languages around is because they have focussed too much on leaving all their old insecure badly designed baggage hanging around in the name of backward compatibility, and just layering new functionality on top of it. It has the most inconsistently developed standard library full of overlapping redundant functions, and it takes new developers ages to figure out which parts they have to stay away from for security reasons. Even PHP 6 seems like it is falling short of its original goals of cleaning it up.
If you wanted a CMS project that followed PHPs development philosophy then you'd probably want PHPNuke or something.
Drupal as a project early on decided that it wanted a cleaner design and wasn't going to be scared to make drastic changes to fix its problems. That has pretty much been its main philosophy as a project, and anyone wanting a different philosophy probably isn't going to be happy.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
It is useful if we can't use it?
As someone who has been involved with numerous drupal implementations and configurations, it has been a frustration of mine the amount of undocumented and poorly functioning modules that are available.
My experience of adding a module, and that module breaking other modules is an experience I'm certain that many of us have been frustrated by.
The experience of adding a module, and not knowing how to use it is something that I experience often. The effect of not knowing whether the issues I am having are because the module is broken - or because I am not using it well - is a frustration that has the effect of stopping work. Stopping the moving forward of progress on my project. It changes my ability to rely on the tool, and to know that I can rely on the tool.
Drupal is an amazing tool, and as it is, has some incredible functionality. What I am saying is that if there is a way to slow down and actually make things work well (not leave the good development behind) and document it, that would be what I would like to see, as someone who uses drupal and wants to see it grow.
aw
the debian model has something to learn from
Focus on stability in the major release and have a testing release that changes more rapidly until another point of stability is reached.
I think this idea could easily be applied to a project like drupal and would provide a place for both sides of this argument to fully participate in the project/community.
I think this model would be healthy for drupal in the long term.
It's time to take the role drupal plays in the larger F/OSS ecosystem more seriously.
Agreed
Boris Mann wrote:
Yes, you mean that Apress book that will cost 44.99 US dollars ? 8 months, you say ? It takes a long time to write 375+ pages of documentation... even for people who know core because they are core developers.
It takes a lot of time to write good documentation. Even when the people who write that documentation are experts. Shouldn't we draw a conclusion here ?
Mine is this one : these people should have taken half of this time off to properly document the internals of Drupal on drupal.org. Or maybe they could take 10 minutes per day every other day to respond to questions asked on the forums, questions about the core. It's not too late to do that.
Never mind, some hard core people do that already (Heine, for example). But that's a rare thing (and he's a rare find).
Another suggestion : *some* people who deal with the community all the time, because of their assigned role, look like they need to develop human skills. It's not a question of age. You can be 20-something and have these skills. If you don't like people, do something else with your life. :) It's perfectly ok to NOT like people. To be impatient, and abrasive, but since I consider myself part of this Drupal community I would like these "hot heads" to either move on to other things in life or to improve on their human skills. Hopefully people around them who are friends will show them the way.
Caroline
A coder's guide to file download in Drupal
Who am I | Where are we
11 heavens
#debian vs. #drupal-support
For a long time I have contrasted my experiences in these two IRC channels as how to conduct good support, and how not too.
I have often found #debian to be a good example of how abusive and arrogant people who think they know more than you can be. They are not the good messengers of the social value of Free Software. #debian isn't alone in this, but are just one of many examples where people feel they are in an experienced elite who are too good to answer simple questions.
One of the things that drew me into Drupal, and has led me to help out on IRC (when I have the time), was the friendliness of the folks helping out in #drupal-support. I could always get pointed in the right direction, whether I had a serious question, or just a brain freeze when I couldn't see something obvious. No one mocked me, no one slighted me with "RTFM then ask the question."
Though I've noticed recently the dynamic is changing; more people are idling, more people are joining, and its going towards #debian. I don't mean to flame anyone who does solid work there. I don't think its bad yet, and will still make my comparison. I am worried though that I see more flippant answers, and calls to RTFM when sometimes (myself included) its hard to find the documentation you need, or you just don't understand something and want clarification if you can get it.
So I give a major +1 on keeping the support centered around being not only technically accurate but also welcoming and supportive to people at the various skill levels withf Drupal.
Book process
Hi, Caroline. I'm one of the developers who took the time to write the book.
My process for writing the book was to start with reading all the code. When there was something unclear or something I didn't understand, I documented it in the code and c