By blackhalobender on
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.
:)
Comments
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_modules
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
NancyDru
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
NancyDru
---
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
NancyDru
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
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
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
--
Larry Garfield
http://www.garfieldtech.com/
Thinking Functionally in PHP: https://leanpub.com/thinking-functionally-in-php
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
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
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
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
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
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
_____ 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
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
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
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
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
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
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
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
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
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
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
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
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_development
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
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
Sharique Ahmed Farooqui
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
- Alan Tutt
Exceptional Personal Development for Exceptional People
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
--
anawillem
http://jellobrain.com
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 contributed the documentation and fixes back as patches. Here's an example. So the documentation went right into Drupal itself.
I also answer questions on #drupal-support and the occasional forum post when I have time. I encourage everyone to do the same as you go up the learning curve; that lessens the curve for everyone.
P.S. 44.99 is the list price of the book. I don't think anyone pays that; Amazon has it for under $30. Use a link that has the Drupal Association ID like this one and Drupal wins even more.
Threads like this scare
Threads like this scare me... I jumped onto the Drupal wagon when 4.7 was still very much there, but when 5.x was also gaining momentum. I learnt that I had to choose, because 4.7 modules and themes apparently could not work in a 5.x environment. OK, so I asked around, and decided to pick 5.x, hoping that the older modules would "soon" be brought up to level with 5.x. I'm relatively happy with my choice, although I am getting the feeling that the number of 4.7 modules being ported to 5 is decreasing - just a feeling, can't prove it. My hunch (fear?) is that when 6.x is more or less "stable" (whatever that means), 4.7 modules will simply be dead, and 5.x modules will come to a standstill soon after 6.x is there.
My request / pleading would then be:
- make 6.x a better CMS, and definitely not a different one. A baker tries to bake better bread. He does not try to make shoes.
- make sure there is backward compatibility, at least with regard to 5.x modules and 5.x content. Drupal is gaining momentum in the "serious" world, with big sites from mainstream organizations using it. The worst thing it could do to itself is disappoint these serious "customers" by all of a sudden telling them that their hard word in collecting content and in designing their own solutions will be of no use when 6.x is out. Changing the API can be no excuse for disregarding backward compatibility. Sure, there must be growth, there may be additional functions etc., but don't forget what is already there.
- and take a break... Don't go too fast... Core developpers need a vacation every now and then too :-)
Ludo
The cost of backward compatibility
As a module maintainer, I do understand the frustration at having to upgrade a module each version. However, backward compatibility causes its own set of problems.
Take Form API in Drupal 4.7. It was 10x as secure and robust as the "do it yourself" method of form handling in 4.6. But there was simply no good way to support both the old form_* functions (which generated strings) and the newer array structures at the same time. The older string-based system also had huge security holes, because each form author was responsible for writing his own validation and security checks. Even the best coder is going to screw up sooner or later and leave a gaping security hole. Not supporting the 4.6 basic form functions in 4.7 was a security feature. If 4.6's forms hadn't been dropped, Drupal would not have been the most secure CMS at OS-CMS last week. (Rasmus had to look really hard to find a hole, and the one he found was rather obscure.)
Having done a few 4.7-5.0 module upgrades, honestly I can say it wasn't that bad. :-) Some required nothing more than dropping in a .info file.
Now take the biggest change so far in Drupal 6: The new menu system. It's much more flexible, much more logical, and much faster than the old one. It's a solid improvement. How would we support the old one at the same time? The old one was based on having a giant array in memory that had to be build on each page request. Supporting that in Drupal 6 means that we still have a huge array in memory, which negates all the speed and functionality improvements in the new system. So we can have a faster system, or we can have the old system. We can't have our cake and eat it too.
If you insist on backward compatibility, then you hamstring your ability to innovate. If you allow yourself to innovate, then you'll break backward compatibility and require more work from people who want to keep up. Either way, something is going to suck. :-) The Drupal community has made a decision about which form of suckage they'd rather deal with.
--
Larry Garfield
http://www.garfieldtech.com/blog
--
Larry Garfield
http://www.garfieldtech.com/
Thinking Functionally in PHP: https://leanpub.com/thinking-functionally-in-php
New developer perspective
I just discovered the greatness of Drupal. I am in the planning phase of my first site. I was "planning" to use the 4.7 version because none of the modules seem to work with 5. I may have to reconsider my choice for development. I didn’t mind being one step behind if it gave me the advantage to have more functionality with the contributed modules, but now I will have to contend with being 2 steps behind. I haven’t even launched a single site with it yet!
If you birth your children to close together you end up with a house full of screaming babies and no one wants to spend much of their time in THAT house. Ask my Grandmother! I think she would agree that you should give them sometime to mature before you push out another one.
I really am impressed with this tool and I am excited about developing with it. Thank you for all the efforts and time.
Myst Powers
Geared Design
If you're still able to...
... I'd say go with 5.x, given how things are going. You're right to be concerned about being 2 steps behind.
Problem is
I need to implement some very specific functions for this distributor extranet I'm developing for my company. I’m too new to Drupal to be able to do this without the contributed modules. Not sure what I’m going to do now.
Myst Powers
Geared Design
I have been thinking about this problem a lot
There is no easy answer.
I think that this is the crux of the argument. Drupal 4.7 is in many ways what pushed the Drupal project into the popularity it now enjoys. If you look at the number of modules that were developed for it, the number of themes, the huge number of sites running it and the number of people who are still choosing it as a better fit, they all point to the fact that it achieved something significant; a critical mass.
That is why I believe this thread to be so relevant to Drupal 6 development. If people are deciding that 4.7, despite the things it doesn't do that 5 does, is a better fit, we should ask why.
Unfortunately a reality of the way organizations deal with technology is a fear of rapid upgrades. There is also a cost involved that many groups, like small non-profits who struggled to raise the funds to deploy a CMS to begin with, simply can't meet.
There is the fact that many people offer professional Drupal services at low rates for whatever reason, and can't afford to always spend time learning new APIs, or paying someone else to teach it to them, or do that work for them.
I have no doubt the Onion, MTV, and other well funded Drupal projects can invest in upgrades, but what about the small non-profit that can only pay to have significant work done on their site once every few years? Don't we owe something to that part of the community too? And what about the parts of Drupal services/user community that supports such operations?
Not all sites need to upgrade...
Many of the features that came with 5.x were not of interested to my company (blocks by roles, improved caching and some others). Many of the sites we make are target sites with few repeat visitors. A couple dozen 4.7 sites will never be upgraded to 5.0. Also, we have been spending serious dev/theme time on a 5.0 site that hopefully will relaunch next months. Most likely it will not go to 6.x any time soon.
Yet, to stay on the tech curve, all the web dev folks in the office will pick up 6.x as soon as it comes out.
Just because a new version of Drupal comes out doesn't mean the a low-budget non-profit needs to upgrade. The same is true for a majorly funded site. If the cost/benefit of the new features against the implementation cost is not adequate, then don't upgrade.
----------
Blog
Trouvé Media
Don't forget though
That security updates etc are only maintained for the current version and the one before, so staying current is key.
Which modules?
LOTS of modules have Drupal 5 releases. Which ones are you missing? Most of the "first tier" modules had Drupal 5 releases before Drupal 5 itself had a final release.
I just did a site upgrade from 4.7 to 5 a few weeks ago. Of the modules we used, by the time we did the upgrade, one had no Drupal 5 release yet (invisimail). And that one was easy to fix by just dropping in a .info file, because none of the APIs it used had changed in the slightest. It does happen. :-)
And if you're waiting on a specific module and building a commercial site, you can always contact the author and see about sponsoring an upgrade. I had someone do that to me on one of the modules I maintain that I hadn't had time to upgrade yet. It was really quite inexpensive and got the module upgraded in a timely fashion, and everyone benefits from it now. As sepeck said earlier, Free Software is not free, you just pay for it differently. :-) (I highly doubt any module maintainer would turn down a reasonable upgraders fee, or feature-adding fee, or whatever else you need them to do.)
--
Larry Garfield
http://www.garfieldtech.com/blog
--
Larry Garfield
http://www.garfieldtech.com/
Thinking Functionally in PHP: https://leanpub.com/thinking-functionally-in-php
This is a community, folks
Everything done here is a result of volunteer effort. The Drupal development happens because people are interested in doing the work. If the weight of interest is in making Drupal better, then that's what is going to happen. If the weight of interest is in slowing down, then that is what will happen. And these are not mutually exclusive, either. Maybe someone so motivated will make a sort of Drupal release bridge module that will enable backwards compatibility for older modules to run on newer releases of Drupal. I cannot imagine the awful performance hit such a module would entail, but there's nothing preventing someone from doing it. The doors are open.
That said, I guess I have a hard time with all the "you should" kinds of comments here. The way to change things is to step in and Be The Change. That is how just about all that is Drupal has happened so far. That is why Drupal 5 is so much better than 4.7, and why 4.7 is light-years ahead of 4.6, and let's not even talk about 4.5 at this point. When it comes down to it, I suppose many if not most people administering Drupal websites don't ever run up against its limitations. And yet the limitations are there. The simple fact is that Drupal 4.6 does not scale well enough for any websites with significant traffic -- not without some serious TLC on the sysadmin level and perhaps even hacks to the core. Fixing those problems means changing its API. There ain't no such thing as a free lunch. If we want improvements, the API must change.
Same goes for the documentation. As a member of the team, I know excruciatingly well just how limited our documentation is. We sure could use help from some of the people piping up on this thread. Any volunteers? Go to the handbooks and add comments to pages you find incorrect or unclear. Add child pages at the appropriate places and fill in the gaps. Be The Change.
(And heck, if instead you decide to go off and write a book for a publisher instead, I won't criticize you in the least. In fact, those kinds of efforts help the greater Drupal community as well, imho.)
Personally, I cannot imagine developing websites based on 4.7 now. And once Drupal 6 reaches a stable beta, we'll probably be pushing into developing on D6 instead of D5. Why? Because we want the best, our clients want the best. Change in the worldwide web is not slowing down, it's accelerating. I plan to be a part of that any way I can.
Be The Change.
(And if Drupal is changing too fast for you, and there's enough interest, you could always start a fork, something like Drupal Classic [though "Drupal" is trademarked]. Everything is GPL. I really believe the community would be seriously hurt with a split, but if there's a strong interest in going slow, there's nothing stopping a community from sprouting up around that vision, too.)
Laura
_____ ____ ___ __ _ _
design, snap, blog
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
a couple of points of debate
you say "If the weight of interest is in making Drupal better, then that's what is going to happen. If the weight of interest is in slowing down, then that is what will happen."
That is a distortion of the position being taken by the people in this debate. The question is how to best make drupal better.
Does the rapid pace of core api change prevent drupal from improving and being more stable? That is the question. Would drupal be made better by taking a year to fix the bugs and make things like cck stable and more usable, rather than starting to develop yet another api before that work happens?
Does the rapid rate of change foster or hamper the growth of that community? does it serve the best interest of the majority of users? I don't know the answers, but I would like to participate in a genuine discussion about these issues.
I also think that it is not really accurate to say that most drupal development is done by volunteers. While module developers are not paid by "drupal central command" they tend to develop modules as part of professional labor. While there is no paid central code team, most patches are submitted by people using drupal in professional or organizational settings that don't really qualify as "volunteers".
Participation in the larger community is indeed voluntary, that does not mean that drupal is the result of volunteers.
I'm not interested in telling people what to do, I'm begging for them to please take certain issues into consideration as they decide for themselves what to do.
I'm trying to advocate for people that have no voice in the community, but who's organizations' use of drupal has benefited the drupal community, who's hiring of drupal developers has facilitated the growth of the project and who feel frustrated and left behind.
....
I'll skip the bit about volunteers vs. um, people whose day job is Drupal. The overarching point is that all of the humans who work on the project have no coordinated command structure: "hey, it would be great if we worked on X for this release", and then all decisions etc. are done on the open issue threads as to what actually gets in.
And again, I hear "modules" (== contrib, in which case you're on your own: drupal.org hosts these as a service, but it is up to individual maintainers how well or badly they mantain those modules) vs. Drupal core.
You've mentioned "make CCK stable" a couple of times in thread. That is a contributed module. There are pieces that have gone into core, and will likely be more pieces of it over time. But other than that....it means coordinating and contributing directly to the CCK module, the same as can be done for Drupal core or for any contributed module. And the nice thing is, there are many fewer people around a single contrib module, so change can be enacted much more quickly and easily.
Whoa. This is very interesting to me. So these organization hired Drupal developers who didn't make a plan for forward compatiblity / migration? So, yeah, that's certainly painful, but has little to do with Drupal-as-a-project. Without knowing more, sounds like bad business.
Again: *why* do they feel left behind? Which modules are not available for newest versions that they must have? Why must they upgrade?
Perhaps specifics would help. I feel that core API changes from 4.7 to 5 were minimal. We've acknowledged that 4.6 to 4.7 was a painful leap. Going forward, there will be other changes, but the work needed to update contributed modules is increasingly better documented, and all the "first tier" contributed modules generally make the leap quick handily.
--
The future is Bryght.
Frustrated, but understand
I am stuck at 4.7 right now because of a contributed module. the name of it rings fear for many :) Flexinode. Back when I set up our site, it was the ONLY flexible content creator. Between the help of volunteers on here and some folks in my company we managed to make it work for our needs. We now have over 1500 nodes that were created with flexinode content. The problem is, flexinode never *really* worked the right way, and it lost its maintainer. Ber has graciously taken over the spot however before it can be released for 5.x, he felt it important to make work properly and stable for 4.7. I wait patiently for him to continue his fine work..offering to help with testing since I am not a developer.
Why not switch to CCK everyone asks...Well there is no GOOD conversion from flexinode to CCK, and with over 1500 nodes, I cant risk it.
Why update to 5.x then, stick with what works.....Well because 5.x has many many NEW modules that will definitely improve our site, and because of the security concerns raised with older versions and also with 6.x coming, being 2 versions behind seriously scares me. Once maintainers move to new versions the old will no doubt be left in the dust.
It is frustrating to see development moving quickly on newer version while stuck where I am, BUT I understand too that I am not PAYING for this great tool, and that means I have to be patient.
I don't see anything wrong with getting to it when it comes to the next releases of Drupal. Just don't forget about us "older generations"
flexinode converters and reverse bounties
it's hard to hear that you are having such a hard time waiting for someone to write software for you while 5.x is up and running. have you considered a reverse bounty to raise money for a more substantial reward for the writing of a better flexinode converter?
Flexinode is not Drupal
Flexinode is a contributed module. Slowing down the development of core Drupal would not make one whit of change to the state of Flexinode. Whether Drupal evolves quickly or slowly, Flexinode's lot is with the Flexinode module maintainers and community members to are interested in making it better.
That may suck for people who do not have the ability to update or port content over from Flexinode, but that is the state of any open source activity where people "scratch their own itch." The issue of the state of Flexinode is, from what I can tell, off topic from the main thread, which is the question of whether Drupal core is evolving too quickly. I don't believe it is.
Laura
_____ ____ ___ __ _ _
design, snap, blog
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
And I didnt ASK
for it to slow down, I was simply replying to the post which asked " why some people may feel left behind". I lay no blame on anyone, nor did I ask anyone to fix my problem, I have been trying diligently to work it out myself, at which point I would share my discovery with others. I have expressed my gratitude to Ber numerous times for his assistance with flexinode and other modules. I have no problem with him "scratching his own itch". I understand COMPLETELY the nature of open source.
Flexinode in my post was referring to a module that has caused me to be unable to move to 5.0. It is NOT off topic since my post referred to it as a REASON some may feel core is changing to fast. One of the reasons many people use Drupal IS in fact the contributed modules, so if core moves way too fast for contributed modules - YES people will feel left behind.
Implying it "sucks to be you", and dismiss a post as off topic simply because you dont agree with it? wow!
OH I SO DONT AGREE
When was the last time" the community" voted for an upgrade or a release date in development? When was the last time "the community" voted to set a list of development and documentation priorities?
NEVER.
Would you and Ber and Boris get yourselves out of the way of letting "the community" decide what is best for "the community"?
Or is "the community" something that suits only the personal needs of the very elite group of developers who get to be the core "deciders" of what goes on in Drupal?
Answer that, and you'll have the reason for the importance of this thread.
I've raised this same issue in the development mailing list over a year ago. Guess who got racked over the coals and excoriated for even suggesting that jumping to D5 was a bad idea given all the cleanup and maitenance work needed for 4.7?
Yah.
And here we are again.
Put the development timeline and list of priorities to a vote. Make it democratic. Let "the community" decide.
I mean, it's not like Drupal developers need to write a module for that --or did they forget that POLL was once part of core?
/ liza
Liza Sabater, Publisher
www.culturekitchen.com
Community driven doesn't mean democracy
Drupal isn't a democracy. Dries makes the final decisions.
The community is divided into people that do things and people that don't. The people that do the stuff have far more influence over how that stuff ends up working than people that just talk about it. The development and documentation efforts don't have priorities (although the people doing the work can have their own priorities), they have stuff that gets done and stuff that doesn't. Wishing for something doesn't make it happen.
All these people wanting longer support for older versions, just need to move from the passive group to the active group and collectively make it happen.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
If a person's definition of work is SOFTWARE DEVELOPMENT
Then they are elitists who should not be talking about "community".
The software developers ought not be the only people making decisions about releases or what happens in core if they are so wanton to "respond" to the "community's" needs. Plain and simple.
"Community" is one of those words that have become so incredibly cliched among technies. Kind of how "conversation" nowadays has been emptied of meaning by "web 2.0" marketers and politicians.
--
Liza Sabater
www.culturekitchen.com
Sheesh
I'm sorry, but if you don't like the fact that the people that provide the most value (and it's not just software development) get the most influence over things (and I say this as someone with less influence than you) then maybe being part of an open source community isn't going to be all sweetness and light for you.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
Excellent idea!
Every time a member of the Drupal community requests a feature, reports a bug, posts a patch, tests a new version, contributes mockups, writes documentation... Why are those 'votes' the ones that matter in this community? Because in Drupal, things only happen when individuals volunteer to do them, step up, and make things happen.
The 'elite' in Drupal are, for better or worse, people who contribute. That is what puts them in the circle of core contributors and direction-shapers. I've been around for two years and some change -- I got involved because I needed something fixed and I tried to fix it. There is no secret cabal, just people who build sites, people who code, and people who contribute to the development process in whatever ways they can. None of this happens in secret, but admittedly there is a high barrier of *time* commitment to really get deep into the process. There's no real way around that.
I think everyone agrees that the 4.6 to 4.7 upgrade process broke everything and was tremendously painful. And there are also several modules -- like Flexinode -- that were never properly updated for 4.7, and never updated at all for Drupal 5. The same problems are encountered by users of closed source software like QuarkExpress, where extensions written for one version are rarely compatible with even minor point revisions. (Anyone who remembers the Quark 3.0 to 3.1 update will shudder with me...)
Drupal developers do not break APIs for fun. They change APIs when it is obvious that core code needs to be refactored for flexibility, performance, or consistency.
--
Lullabot! | Eaton's blog | VotingAPI discussion
--
Eaton — Partner at Autogram
Excuse me, but I don't get it
I don't quite see how I am in the way of anything. There is nothing saying everybody has to move together. If a critical mass wants to move in a new direction, there is nothing to stop them. In fact, the GPL affords just that kind of activity.
Democracy? This may seem like an unfortunate metaphor, but do horses vote on which way to go? Do birds vote on which way to fly? People are just doing things that interest them, and they see a personal benefit of collective engagement in that endeavor. It's a democracy of deeds. Nobody is forced to use Drupal, nobody is prevented from forking Drupal, nobody is forced to upgrade, nobody is forced to enjoy the benefits of whatever comes down the pike from the worldwide community.
Liza, I've been behind you on a lot of issues within and outside of the Drupal community, but here we stand apart. I just don't see it.
Laura
_____ ____ ___ __ _ _
design, snap, blog
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
Slow down?
As long as I do this for my own fun, I have no intention to stop. We are actually damned slow but those pesky feature freeze months are needed to release something we can be proud of.
Just yesterday I upped the form API reference though.
The forums are clogged with unanswered questions -- we surely do not visit the same forums.
--
The news is Now Public | Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile. | Blog about life in Hungary
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
$.02 from a new drupaler
I just began working with Drupal a couple of months ago. I am sympathetic with some of the complaints here (a lot of questions do go unanswered on the forums, for instance) but I also approach Drupal with the attitude that I have to take primary responsibility for figuring things out myself, with the help of the community (past contributions to documentation and, sometimes, new answers to my questions).
As I learn more, I get closer to makiing contributions myself. And I am looking forward to doing more of that. I'm not really afraid of new versions, as from what I have observed each version builds on the last. What I learn in Drupal 5.x will change in 6.0, but it will still help me manage 6.0.
So bravo for the developers. I won't ask them to slow down. Whatever they do will benefit us all in the long run, I'm sure.
changes in tools and process
I can't say I've read this whole thread, but after skimming over it, I'd like to mention a few things that some people seem to be overlooking:
More fundamental is the introduction of official stable releases for contributions. Even if Drupal core's API was frozen at 5.x, in a system where nothing has a version number and it's extremely difficult to tell what code a given site is actually using, Drupal would be much more "unstable" than what we have right now. Since we've gotten official stable releases, site builders have a much easier time maintaining a stable site, even if the release system happened on the eve of another change to the core API. For example, the update status module and other tools for maintaining stable sites are only possible because of the new release system, which only came into existance because some of us developers were impossible to stop. ;)
So, it's simply not true to claim that Drupal's development environment has not evolved and responded to changes in the community of people using it. Now, whether or not individual module maintainers choose to use the flexibility is a different question, but at least they now have the choice.
___________________
3281d Consulting
+1
Thanks Drupal!
AGREE
PERFECTLY AGREE
Stop doing stuff that aren't realy needed for at least 60% of drupalers. A 'change language item' its not the main upgrade that gotta be changed. There are MENU's problems, menus bugs (http://drupal.org/node/133142) and lots of question(some stupids) at forums about
5.x
I also think that's VERYY important upgrade drupal(6.x, i'm quite sure its gonna be great), but if you have just release a version of something(anything) and there are BUGS that have already been found, you gotta put that at least 80% of those bugs working or at least have a nice support team(Maybe something like an Online-Help-Desk-Cender) for help newbies drupalers.
Lucas Boaventura
Contact: sanlucas@triang.com.br
Great ideas
The menu improvements are truly important. That's why the API is going to break when upgrading to the future Drupal 6. As Larry Garfield notes below, fixing the menus requires changing the API. There's no way around that.
The help desk is a great idea. Perhaps you'd like to lead the charge and organize the volunteers to do this. If there are a bunch of people who have the time availability and would like to facilitate a help desk, I don't think anyone here would get in the way of that.
Laura
_____ ____ ___ __ _ _
design, snap, blog
_____ ____ ___ __ _ _
Laura Scott :: design » blog » tweet
RE: The Developers ...
hello
i think the development is not too fast in general, but maybe there should be more focus on a few things:
maybe it's a general question of the menu system (sorry to promote again :) http://drupal.org/node/129111
(sorry for bad english - and thanks in general for all the well done coding)
greetings momper
In progress
The new menu system for D6 is faster than the old one. It will improve performance for logged in users. It cannot be done without breaking backward compatibility of hook_menu().
This is why Drupal's APIs change each version. The stuff you list would not be possible unless we allowed ourselves to break things at fixed points.
And actually there's a lot of caching for logged in users already, just not page caching because the page changes too frequently. The menu, filters, some Views (contrib) and various other things are already cached. Could there be more? Maybe, but it may involve breaking API compatibility again. :-)
--
Larry Garfield
http://www.garfieldtech.com/blog
--
Larry Garfield
http://www.garfieldtech.com/
Thinking Functionally in PHP: https://leanpub.com/thinking-functionally-in-php
Stop this thread
TheWhippinpost said on April 4, 2007
That said, is there any point in continuing this thread?
NancyDru
---
free speech ? ; )
discussion is healthy
A: there are still points raised by both sides that the other side has not addressed
b: discussions like this are a healthy part of the Free/Open Source development model
CentOS
Because of Drupal's (relatively) short release cycle, I would have difficulty recommending it to a client who I didn't have an ongoing working relationship with.
I like the way CentOS (among others) approaches the issue of innovation vs. product lifetime. Fedora developers can innovate to their heart's content (as far as I know), while CentOS provides stability for the medium-term. As a result, CentOS gives clients the option to upgrade less often, and it gives them more freedom to decide when they upgrade, so they do not feel "forced" to do so every 6-12 months.
Is Fedora/CentOS a reasonable comparison? And if so, can the Drupal community imagine doing something similar?
Not *completely* accurate.
I can somewhat agree with what you say.
I don't think Fedora/CentOS is a reasonable comparison, because CentOS is based off of the Redhat Enterprise Linux source packages. CentOS doesn't upgrade until after RHEL has made an upgrade (look at right now, RHEL 5 came out earlier this month, CentOS currently has a CentOS 5 Beta release out). I'm guessing you mean Fedora/RHEL. That would be a more appropriate analogy.
I think it's the job of the companies and consultants that provide drupal services to support older versions of drupal for longer than what the community does. But I think the cry for help from most people (even some companies and consultants) in this thread is that "I want the community to support a Drupal release for longer than what it currently does" (not going to happen). The better alternative is to have (the ever elusive) someone create a "distribution" of Drupal that is supported for longer than a year.
That's going to take a whole other community to form, possibly causing a fragmentation of the Drupal Community. Although it may be the best thing to happen, rather than have so many people upset about how often they have to upgrade. But in my opinion, anyone that has problems upgrading their installation so often (be it lack of time, lack of coding ability to upgrade modules, lack of other resources, etc.) will be hard pressed to build up and support another community. That's where a company can come in.
To use the analogy, the community needs to continue innovating (Fedora) while some company pops up to support drupal releases for longer than a year (RHEL). That company could charge for support contracts (and whatever else Redhat charges for using their distro). CentOS in the analogy would be another community that could form around what the company created.
There are probably companies already doing this by supporting their client, rather than releasing a modified version of an older Drupal release for download by the public.
*cue the drupal companies to chime in on how they are doing something like this already*
How can one ask to stop or hold back innovation?
Drupal is what it is today because innovation has been at the heart of Drupal. Drupal has one of the strongest developer community I have known and it also has few of the smartest people leading the change from the front.
Speed of change should not be an issue at all. We all live with change everyday. We have to adapt ourselves to embrace it.
When my company provide services, we put in options for Training, Documentation and also another option for Annual Support.
Drupal upgrade can be simple or complex depending how it has been architected and developed. There are best practices and guidelines and more often it is noticed that they are not followed. In this case, it can be a challenging task for upgrade.
Everyone agrees that Drupal documentation is not current. As developers, we all love to write code but are sloppy when it comes to documentation. Community is definately trying to keep up but with the amount of development going on, there is definitely going to be a huge gap.
Drupal today is where SAP R2 was in early 1990s and when SAP R3 got released, it took the whole world by storm. Drupal 5 is a *AWESOME* ( as Dries presented in his video - State of Drupal) - I think this is just the begining. We all are in exciting times and we must learn to keep up with pace and do our best to help in whatever form we can.
--
Roshan Shah
T : 604-630-4292
Vancouver, Canada
Skype/GoogleTalk/Yahoo : bpocanada
best practices and guidelines!
Dude, sign me up for the well planned path. Since I'm in the architecture and planning stage of my first Drupal site I’ve decided to keep the “ever-changing” in mind. I’m going to start with v5 and I’ll roll v6 if I find it necessary. All of your comments have been very helpful in my decision on how to approach my first endeavor. Keep up the great work. This is an amazing community and resource. It is very encouraging!
Mystical
Geared Design
The People That Do Nothing and Expect Everything MUST b Stopped!
As a new drupaller this thread is a little disturbing to me. I just wanted to respond and give my take on a few things...First off, I wanted to give a big THANK YOU to all people both developers and non-devlopers who step up to the plate and contribute. If you develop for core, thank you. If you contribute and maintain modules, thank you. If you work on the docs, thank you. If you just answer a forum question every now and again, thank you. Your work, time and effort is very much appreciated. With all the complaining, I just felt as though that need to be said so I said it.
Anyway, now I disagree with the whole "devlopers need to slow down thing" for several reasons. Having a relatively speedy development cycle/lack of backwards compatability attitude has advatages and disadvangtes however I feel as though the advantages of drupals philosophies far outweigh the disadvantages. The tradeoffs have been well documented above so I won't go into them in detail. The whole point is drupal has a philosohy...It may fit your needs and it may not which is ok...It is obviously working for the people who are actively involved developing because if it wasn't they wouldn't continue to do it...At some level we are at the mercy of the people who do the work. Those people have made it clear what direction they want to take the project in. At least I think they have. If their philosophy doesn't work for you, go find something else that does and STOP acting like everyone OWES you something. I got news for those who act like that...NOBODY OWES YOU ANYTHING... Now, not everyone who opposes the fast development cycle is acting like that, but a few too many are. I personally am sooooo sick of that attitude.
Now that I got that off my chest...I have to agree that the docs leave quite a bit to be desired...I also have to agree that the forums have quite a few questions that need to be answered...I think the questions we need to be asking ourselves are:
1) How do we improve the docs, explaining the changes between versions, etc? How do we seperate the content between verisons? How do we organize the docs in a better way? Is that new module thats coming out by those boys at Lullabot the answer? Is it possible to form some sort of pre-release doc team that will meet with some of the core developers and put together detailed explanations of changes between versions and have these docs available the instant a new version is realeased? Can we organize some sort of doc writing party some weekend where everyone just sits down and hammers out some docs?
2) How do we encourage more people to respond to questions in the forums? Will better docs reduce the number of questions? What systems can we set up to ensure that the forums are being maintained and questions are being answered...(On this note, for those who write crappy forum questions...you don't deserve an answer...Ill be damned if I am going to put an effort into answering your question if you don't put an effort into writing it. Do some freakin research... Remember that nobody owes you anything!!!)
The simple fact is that quality forums and good docs are VERY IMPORTANT...Having well maintained modules is also VERY important...Getting these things right are vital to keeping the community growing, building and improving. We need to ask ourselves what are ways that we can improve in these areas AND be on the cutting edge...because that is what the Drupal project is all about. The solution to the problem isn't to tell the guy redoing the menu system to stop that and rewrite the docs first...At least in my opinion.
The bottom line is I don't think the answer to Drupals problems is shifting one of Drupals core philosophys...We CAN have a rapid development cycle and good docs...We can have forums with a majority of questions being answered. We CAN have stable modules that are updated whenever a new version comes out. These problems aren't the core developers fault. In my opinion they are the fault of every single person who takes something from Drupal and doesn't give something back. These problems lay on the shoulders of those who say "I could make the docs better, but Ill leave that for someone else." EVERY SINGLE PERSON IN THE COMMUNITY needs to chip in in some way shape or form. For those who can't develop or write well, make a point to try to answer 1 forum question a week or month. If you make money from Drupal and don't have the time to give anything else back, donate some freakin money every now and then...
I can tell you that as soon as I launch my first Drupal site, I am going to head straight for the handbooks and try to dig right in there trying to do my part. I think if everyone adopted an attitude of what can I do, the community would be a better place and quite a few of the issues raised in this thread would be rendered obsolete.
Just my 2 cents...Feel free to light into me now :P Please forgive any typing/spelling mistakes...I am tired!
---
Just so you know : ) i saw that before it was edited!
found myself wondering what sopped meant : )
lol
I thought I was pretty quick...You caught me!
you miss one important point
one of the primary complaints is that the speed of change in the core API prevents many people from contributing documentation and code.
When knowledge expires every 6-9 months, how can you ever expect people to give back in the way they should/want to?
---
I don't think knowledge/information expires. Many things translate from a template side to all three versions (4.6.x 4.7.x & 5.x) because phptemplate hasn't really been altered that much. With regards to API changes, they are always listed making it that much easier to update modules, custom code and such. This idea that when an API is changed it renders "information" useless is an alarmist reaction. The sky isn't falling......
Maybe I have...I still
Maybe I have...I still believe that there are things we CAN do to make things better without altering the speed of drupal development...I think we need to try and do some of those things first before we ask the core devs to slow down. There are so many things we can do to help alleviate the problems people write about here before we go asking to slow down the dev cycle to 1.5 yrs or whatever... I don't know about you but I want that menu system/improved performace/whatver killer feature they are coming up with, etc... My perspective is the quicker we can get to the IDEAL menu and corresponding api the better...Once we are at the point, hopefully the api won't change too much for the menu system...Let's get it right and absoultely nail the menu and corresponding api with 6 and then there will be no need to change it from 6 to 7...At least not big changes. Just imagine...What if they nailed the menu system in 6 so that it was as fast and efficient as it could be...We may be able to use that same api for 7, 8, 9, etc...The thing is as Drupal grows, the community and the project is finding its way. We are correcting mistakes, getting better, etc... I have visions of a drupal that KICKS ass... I want to get to that point as soon as we possibly can. I am more than willing to sacrifice a few headaches and do some more work to get to that point in 3 years instead of 7...
Let me paint a picture of my vision for you...First off, I think the docs are crucial...The flow of information is vital. What if there was some way that we could release killer docs for 6 immediately following the official release of 6, detailing the difference from 5 in a way that most people can understand... I believe that the sooner we can get good information out there, the further ahead of the curve we will be. The problem is as your are describing it is that too many people are behind the curve. You say its the speed of development that is the problem. It may be, but I would contend that IF we were able to release good quality core docs in an organized fashion along with videos, it would go a long way towards solving some of the problems. Now this sounds incredibly corny or whatever you want to call it, but I really think that we should have some sort of doc writing bonanza some week around the time 6 is released...I KNOW we can get the information out there quicker and better than we have in the past.
Now lets say, we have those good core docs, that detail the changes. Lets say they are released around the same time 6 is officically released...People that didn't work on development of 6 could then go and read them/watch quite a few vids and catch up so to speak. You would start to see people understanding 6 and being able to use it much quicker and being able to give back much quicker. We need to work on making that curve between versions easier to climb/less steep. Maybe I am living in fantasy land, but I really feel as though things like that should be part of the first steps...
Let me know what you think. Trust me people I see your point. Hell, there is even part of me that agrees with you. I understand that development speed impacts things, but I was drawn to the Drupal project because of the core development attitude...I think that there are other things we can do. Lets start. How can the doc team communicate with devs in a way that would allow us to get at least a basic set of docs released explaing the changes in detail around the same time 6 is official released? Is there a way we can shorten the learning curve so that people are able to give back without grinding new development to a halt? Lets try to answer some of those questions here. Lets come up with some ideas... I have to go, but I will think about things we can do in my head and I would be more than happy to come back here and share them. Why don't we all do the same?
---
all anyone has to do to begin working documentation for D6 is to download D6 from CVS and begin to investigate the changes. Docs for D6 are already being built, specifically how to upgrade modules from D5 to D6.
The new menu system will certainly be nice. Personally, I'm looking forward to the new language hooks. While I understand not everyone has a need for a multilanguage site, the fact remains that when a site is multi-lingual your reach goes beyond that of the english speaking world. This is a big deal IMO, especially if you have an ecommerce or community site.
Nice...I am new to Drupal so
Nice...I am new to Drupal so there are obviously things I don't know...Thanks for telling me this...My main point is that I think SOME people need to shift their thinking a little. I OBVIOUSLY don't have all the answers...I am just trying to get people thinking in a more positive action oriented/beneficial way. There may already be tools in place. Is there some sort of page that says whats going on? Here I am spouting off about building d6 docs and people are already doing it...lol...
---
No there is no page that states whats going on with regards to documentation being worked on..
Module maintainers can already begin preparing modules for D6 using this document. : http://drupal.org/node/114774
far less (in amount) changes will need to done with regards to updating modules for D6 over the amount of changes that were required to go from 4.7.x - D5.
theme devs can also begin working on updating the themes to D6 with this document : http://drupal.org/node/132442
good to hear
I'll take the positive spin on this and suggest that this could be viewed as a slow down to the rate of change in the core api. Thanks. ;)
I thought I was the only one...
Wow! what a thread. First time I've encountered this type of an argument since i've been here (about 2 weeks).
Let me start by saying, I'm a brand new drupal'r and man is this confusing! I come from an XHTML, CSS, JavaScript, CFML background of about 6 years and the structure to the documentation on this site seem almost non-existent.
For the first 4 or 5 days I had no clear cut way of figuring out the easiest ways to install Drupal. The I "stumbled" across the Drupal Handbook for new drupal'ers. To Nancy, I thank you. This was very helpful!
However, to provide some backing to this argument of slowing down, I came across the part about editing the settings.php file in the handbook. It isn't exactly clear as it refers to dburl and db"something". When looking at the settings.php i couldn't find dburl (or dbsomething) like the handbook said. It didn't exist. Instead I needed to refer to baseurl. While it wasn't exactly brain surgery to figure this out, I couldn't confirm what I did was right until i dug down into the comments were it cleared everything up.
So once everything was set up and running, it was time to start plucking away at adding in my content and theming it the way I wanted to look. Didn't need much documentation to do that so I finally came to images. I wanted to create a gallery. I did some digging using the search functionality, but digging through all of the "fluff" was time consuming. Then I found a module (acidfree) which looked like what I needed. well it turns out that this isn't available for drupal 5.x.
So now that I'm getting that figured out, I'm trying to learn how to edit the front page, how to add new menus, and find out a way to specify what menus should be on each page. To me this seems like it is something that would be very basic and there would be some type of documentation on it, but I have yet to find it.
All I'm trying to say is that what is happening here is great. People working together to make a wonderful FREE product in their SPARE time. But what good is to do all of this, if you have people trying to use it but can't figure out the basic ways of doing everyday things?
Honestly, if i didn't personally know someone who all ready uses drupal to develop, I would have moved on. Luckily he has been there to help me "stay the course". From all my reading, Drupal seems SUPER powerful, but I don't have the faintest idea on how to even go about implementing any of it. Great concept, missing the structure.
EDIT: And one more thing I'd like to add: It's very intimidating coming into something trying to learn it (like I am), knowing that as soon as I get my sites to where I want them, another version of Drupal is going to come and replace my current version.
I'm a Drubie (Drupal N00b)
All this presupposes something *could* be done about the pace
Just FYI, no ones driving this thing. Everyone on this thread seems to be convinced that we *could* control the pace of development. But everything here is volunteer. Unless you are suggesting that we start turning down API improvements, then there really is no point to this conversation.
Let me clarify. Regardless of releases, all these patches, and improvements are going to be written. You can't stop developers who need something for a client. They will code what they need and (maybe) return it to drupal.
Similarly, you can't force a volunteer to do anything.
So even if Dries came out tomorrow and said we're only releasing every other year and supporting better.... it wouldn't change much except how fast the version numbers change. Changes would still be as drastic... just a mess of all being under one release instead of multiple releases.
That said, if you want better documentation, make it. If you want to support more than two versions back, do it. I will personally guarantee to everyone on this thread that if you organize a team and step up as maintainer, NOBODY is likely to say that you aren't allowed to maintain 4.6, or 4.5. So feel free. Have fun with it.
But don't presume that we can tell any of the devs what to do, we can't.
Sam Tresler
http://www.treslerdesigns.com
-------------------------------------
"A list of common problems and their solutions can be found in the Troubleshooting FAQ."
Who makes the decisions
True. Dries has the last word on all significant changes to core, even those changes that may appear not so significant. That's a fact.
Caroline
A coder's guide to file download in Drupal
Who am I | Where are we
11 heavens
Drupal, modules and PASTE
I was relectant to add to this long debate, but since I'm somewhat new to Drupal (+- 1 year) I would like to says that I too find the developpment paste I little to fast. When I switch from Joomla to Drupal, I started with 4.7. For a moment, I considered using 4.6 thinking it could be more stable. But since most module where compatible with 4.7, I went with that version. Eventualy 5.X was there. The new look of this version convinced me to swicht as soon it exited the development stage. Big mystake !! At that time most modules where not upgraded for 5.X. For a while, part of my content wasn't usable but I told myself it was just a question of time. To this days, a lot of modules are not compatible with 5.X. Some are even "stuck" to 4.6. Now, I read that 6.0 will be coming soon ?!?! I think developpers should realize that a lot of the strenght of a CMS comes from the modules being developped to extent its capabilities. I agrees with those who says that 5.X is a goob product, but far from being perfect. Why the hurry to reach 6.X ? I think a new user looking at 4.6, 4.7 and 5.X would be puzzed to realise those are almost different CMS.
There are countless number of CMS out there. Saying that backward comptabily is not important is like saying that every new version should be a new CMS. This is synonym of uncertainty and unstability and a lot of people won't invest there time learning to use a product (opensource or commercial) if they know that with every new release, they will have invest more time to master it. No matter what you says, when a new version is release the bulk of the "brains" supporting the product stop supporting the older version. People like therefore prefer upgrading to the new version as soon as possible because support for the previous release get harder and harder to find. Like the first posting of this thread was saying, I would have to says "Stop the developpers..." Or at least, give the time to most of the modules mainteners to catch up...
[Sorry for the many spellings mistake, I hate writing in English !]
Having started with Drupal
Having started with Drupal at version 5, I haven't come up against the issues here around incompatibilities from one release to the next, though I have wished some of the modules for previous versions were available for this one as well. I think it's a terrific product and appreciate the hard work people have put into it. Thanks!
Having said that, though, and I've only skimmed the zillions of messages here, I'll be concerned about recommending Drupal to clients if I have to worry that every new version release is going to mean that certain modules, themes, whatever won't work, particularly if a client depends on them. Some of the comments I've read here seem to be forgetting the client's needs for stability and security. Not to mention their desire to not have me invoicing them for updates that may provide increased functionailty in some regards, but at the expense of it in other areas. I'm no Word fan, but that would be like having newer versions of it not being able to read previous one's files. Some things have to stay stable, and I'd say that would need to be the core application. Innovation is great, but not if it creates all kinds of problems for users and clients.
I'm not blaming that on developers or anyone else. If the path Drupal has chosen is one of rapid development at the expense of compatibilities from one release to the next in favour of improvement and innovation, so be it. For some clients it'll still be the solution of choice, and for others I'll use something else.
I've used Mambo/Joomla for more than a few years now, and they've managed to stay stable across a number of versions, while extensions add lots of great evolving functionality. At the same time there are a number of core functions, like user management, that IMHO are really lacking in it, and superior in Drupal. I wish they'd move more quickly on that. But you have to consider, that if there is no easy way, or no way at all to migrate 1000's of users from one user management process to the next, people won't jump to the next release. This can be problematic if the older release is no longer supported and starts to sprout security holes. Or, they'll move to something else. It's less about what developers can develop - more about what the user needs - and for clients, in my experience, that's a balance between innovation and consistency/stability.
Cheers
Chris Hutcheson
Time-based releases, improved APIs for security, usability
I took the time to read the whole thread. Here's my summary
1) Regular release schedules provide consistency to help organize the community.
-These have averaged around 6 months, with the exception of 4.7, and 2-4 months of stabilization with bug fixes.
-Good communication of release cycle dates is part of good leadership that have made this community successful.
2) Time based releases are more effective than feature based releases.. If we waited for documentation and features that people wanted Drupal would be less effective than it is today.
3) Drupal is currently maintaining two releases and developing one with just 4 core maintainers.
-Drupal 4.6 was release on April 15th, 2005. 4.6 release announcement
-Drupal 4.7 was released on May 1st, 2006. 4.7 release announcement
-Drupal 5.0 was released on January 15th, 2007 5.0 release announcement
This means that 4.6 was supported for 21 months. This is plenty of time to plan for an upgrade of a website.
Slowing down innovative development will attract fewer developers of maintainer quality to work on multiple releases.
4) API changes have attracted people looking for consistency and stability, particularly in terms of security.
-While many Drupal user see internal changes in Drupal as too fast or too radical, Drupal as a framework has attracted many organizations who see the framework as a way to implement consistency and stability in their organization's web publishing.
-The decision to implement Forms API provided a more consistent way to prevent security issues like Cross Site Scripting attacks. Learning one API was much easier than doing advanced security audits of all forms across dozens of modules.
These new APIs have meant there is less overall changes and less to learn.
5) Adding features like CCK to core mean less modules to maintain and upgrade
-It is much easier to have core development resources focus on improving CCK than to maintain hundreds of contributed modules
-Therefore having more core releases makes it easier to upgrade individual sites
6) Slowing down development will not improve documentation
-Everyone who downloads Drupal is a content publisher and therefore a documenter. Yet we don't have enough documentors.
-Slowing down innovation in development will not improve documentation. Developers are not interchangable resources for improving documentation.
7) Usability improvements in core are more effective than contributed or site based usability improvements
-There are many modules that aim to improve site usability
-Improvements in Forms API, JQuery, and the Administration menu in Drupal 5 are more effective ways to improve usability than to pile on contributed modules to less frequent core releases.
Summary
Kieran Lal
That was a well-thought, and
That was a well-thought, and articulately written contribution Amazon
... but I'm not sold! ;)
You make lots of points - a response to each one would be a thesis.
I could possibly, loosely, summarise my initial thoughts with this: The reasoning given to the points you commented upon, cater for a small band of users, IMO.
There are hundreds of contributed modules and there are many thousands of users - You mentioned less than a handful that are being worked-on, to be integrated within core. There are many thousands of users that will most likely never need to create a content type, much less with forms.
And that, really, represents my general overview.
I can best finish briefly by addressing your summary.
1 - Doing it too fast shuts users out in the cold. Additionally, the speed of documentation needed to both attract, and keep the userbase up-to-date... well, I need say no more.
2 - That's a circular argument.
3 - But with all the changes that fix some things, others break... and I believe the forum use here is growing, if anything.
Finally...
I'm sorry, it don't matter if you're the best PHP coder that ever lived, if your life doesn't involve Drupal Daily, it matters not... and that's how most folks operate with Drupal, I'd wager, whatever background.
Mike
------------------------------------------------------------------------------------------
A simple thanks to those that help, a price worth paying for future wealth.
Let's get concrete
You argue that you are concerned with the hundreds of modules that people use and not with the few that are being integrated into core. Let's take a look at the download statistics. From this we can see that thousands of people are interested in views and CCK. This is more than the supposed long tail of neglected modules. We can also see that Drupal 5 downloads overtook 4.7 within 15 days indicating a clear preference for the newer core version than the stable old version.
1 - Doing it too fast shuts users out in the cold. Additionally, the speed of documentation needed to both attract, and keep the userbase up-to-date... well, I need say no more.
The Drupal 4.7 - 5.0 release was 7.5 months long. Are you suggesting that longer release times would fix the support and documentation problems? As the top contributor, or used to be, to Drupal.org documentation I can tell you the documentation problems are not related to how fast the releases come out. Most Drupal core developers are employed full-time doing Drupal development. That allows them to make significant innovations to core. None of the top contributors to Drupal documentation or Drupal forum support are employed full time doing documentation or support. Should we slow down core development because no companies have chosen to hire their support and documentation colleagues? I think not.
2 - That's a circular argument.
Let's take a look at the more than 40 CCK contributed modules. You can now create limitless combinations of features using CCK, replacing the need for many hundreds of modules. CCK and views have made many modules redundant as well as the corresponding support, are being abandoned. While many people wait for modules to be upgraded they have failed to realize they are no longer necessary due to these innovations in core. Moving CCK into core has been a clear success and the download statistics bear out that success.
3 - But with all the changes that fix some things, others break... and I believe the forum use here is growing, if anything.
The reason forum use is growing because the strategies of adding innovations in core have been successful. Many people are adopting Drupal despite having a marketing and sales budget of zero! We have attracted many more users, almost double for the 5.0 release if projections hold. Don't confuse popularity of Drupal with insufficient growth of the forum support base and the documentation base.
In short, this argument blames insufficient support and insufficient documentation on the speed of Drupal releases. As the primary support provider for the CivicSpace, distribution of Drupal, and the top contributor to Drupal documentation I don't see the speed of releases being a major factor. We simply haven't effectively utilized the documentation and support that are available to us effectively.
If you believe that longer release cycles will improve support and documentation then please articulate how having the Drupal 7 release cycle taking a year or longer will do so. You should also address how the 13 month release cycle of Drupal 4.7 improved support and documentation and will have the same effect in Drupal 7. Be sure to cross reference any arguments with growth in Drupal traffic to show that in fact longer release cycles will offset the increased support and documentation burden due to growth in popularity of Drupal.
You concerns are legitimate. But release cycle speed is not the cause, continue to focus your energies on solving the support and documentation problems.
Cheers,
Kieran
Kieran Lal
Again, a well-thought-out
Again, a well-thought-out set of comments.
I know one thing; nothing I do or say here, will change the positions of those "on the other side".
I could, I'm sure, spend hours tackling some of the assertions you posited, but alas... we would only be duelling with each other, rather than effecting change.
This debate will happen again (and no doubt, again more). This is an organisational "thing" - a group mindset/behaviour, if you like - What we're witnessing (and suffering - on both sides), is indigestion; these threads are the burps... they will get bigger, and more painful, as more beholden themselves to this rigour.
I will say this - WRT the forum's here (Hey, it's the easiest and quickest to write!):
Believe it or not, I didn't want to join - Apart from partaking in enough forums anyway, it just never struck my mind that I would need to join and participate... I only wanted the software!
I considered myself "failing" when I had to join. The more I came to rely on it (here), the more frustrating the experience because it was symptomatic of Drupal not holding to the product I expected, when sold-to at the front gate.
My point really, is that people don't procure tools to necessarily become friends with their makers, if you see what I mean.
Mike
------------------------------------------------------------------------------------------
A simple thanks to those that help, a price worth paying for future wealth.
and here it is ...
And here is the issue on your side.
Open Source does not cost less, it costs different. You have to understand that people work on this project for their own reasons. You comments demonstrate that you think you are owed, as if you paid someone money for this software. Continuing to act on that premise will only lead to further confusion and frustration.
If you want software without involvement, then perhaps Open Source is not for you. Perhaps a commercial package is. Perhaps a relationship with a vender or developer who can support your Drupal use is the answer. You found us, we did not have a salesperson call you.
And yes, I see what you mean. Do you see what I and the others mean? This is the root of most of these threads.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide