The experience with working with WordPress the past year and a half has been educating. While the solutions found in WordPress aren't exactly perfect, I'm finding that verses others a lot of what WordPress does, is what I wish other web projects would do. I'm also finding that I develop more per the techniques that WordPress uses for themes.
Plugins
On the topic of plugins, if I had not worked with WordPress, then I would never have seen it as filters and actions. My solution would have been to use the Adapter Class Pattern for replacing functionality. The problem is how to handle allowing multiple implementations and the Adapter pattern does not handle those well. Could use the Observer pattern, which is more or less what WordPress uses.
The solution in WordPress is not tied to any one class, uses an unified API, and is extremely easy to work with. That I think is what allows WordPress to be as simple and easy as it is. Sometimes, adding content, replacing content, and extending, doesn't or shouldn't involve editing source code, but hooking into a filter or action. It is not required to know how it works, just that if you use this hook that you can manipulate the feature to your requirements.
With the Adapter Pattern, you have to know specifically what it is you are replacing, and how your replacement will work with the code. It works well the use cases where the implementation you are handling isn't as simple as filtering content or specifying an action. The advantage is that, you can use the same API within the code to do something else. So a multiple step process would be great for the Adapter pattern.
Themes
For themes, what I've learned from WordPress is that it is not enough to provide data and handle it, but to also provide the API for handling that data. It is easier and a lot more faster for the developer who doesn't think or realize that other non-developers may need to make changes to the theme to handle the data directly. The problem stems from those who do not know the PHP syntax and what problems arise when you screw up that syntax. I think that is why Smarty is used for some templating systems. If you screw up Smarty, you are not going to bring down that page, it just won't display correctly.
I'm not saying that Smarty is better than straight PHP, just that Smarty has its purpose. You can make PHP just as fool-proof as Smarty, if it is done correctly. I suppose, the issue is still one of education. I create iterators with my data, and also methods for handling that data. The work flow is not simple for others and I have to supply documentation for how to use the iterators and methods. I believe that once people know what they can do with the iterators that they find it is easy to work with. Looking at the code, is another matter and you really need to know what you are doing in order to modify it.
Beautiful code is not in the implementation but the use, you are abstracting away difficultly from the user and sometimes the implementation is going to be seriously ugly and there is no way to make it beautiful. The best that can be done is making sure the user doesn't have any problems in understanding how it can be used.
Developing Solutions
It is always my goal to strive to develop the best solution, no matter what, but given my limitations, I think the best I can give is one that is working. That I think is important regardless of the solution. I think developers get caught up on how well the solution functions verses that it is even working. It is not to say that improper or poorly developed solutions shouldn't be criticized, because eventually, the solution is going to have to maintained.
The better the solution is developed, the easier the solution will be to maintain, extend, test, and refactor. That has always been my goal. The problem is that when you work with new patterns, data structures, and APIs, the solutions don't always work out that way.
Roles and Capabilities
The point with WordPress is that, it has shown me solutions that don't work that well. The Roles and Capabilities API and data structures work within the WordPress application, it is just not something you want to duplicate elsewhere. What is great about the Roles and Capabilities implementation, is how the API works and what data it contains. There are probably three or four core ways to develop Roles and Capabilities in web applications. Well, there are many more; anybody who developed any PHP application will have their own, it is just that they'll fall in line with the general other solutions.
What I like about the WordPress solution is that you aren't using levels, which if you've ever developed a solution using them, you'll soon find that it is very limiting. You aren't using the sort of CRUD permissions that phpBB and Zend Framework uses. I'm not saying that the solution found in phpBB and Zend Framework are bad, it is just that for most simple applications, you are more concern with simply if they have the capability to do something and not whether they can browse, but not delete, or read, but not browse.
That is not to say that certain aspects of the WordPress roles and capabilities doesn't fall into that model, because certainly parts do. It is that not enough of it does and that you can still implement the CRUD way using the WordPress implementation. The difference is that instead of having one row, you will have, at most, four or five. Not that it makes any difference, because your concern will be for one or at most two of them and not all of them.
Also, it is difficult for me at least to visualize how every capability would even need most of the permissions. If I just need the capability for reading, why am I needing to tell whether they can delete, there is nothing to delete anyway. I believe those work that way, because in administration, you are going to be implementing the majority of the permissions anyway. Administration, yes, normal web applications you don't, where you still need to be able to tell someone can to do something, but not whether they can delete, read, browse, edit, etc. In this instance, the way WordPress does it works very well.
You can work both ways into any application, it is just that the way WordPress does it, is easier to visualize, easier to implement, and a lot easier to check against. It is the way the roles and capabilities are stored in WordPress that I don't agree with and well, it is something else in developing a table structure, because there are many ways to implement that as well.
If I had not seen the way WordPress developed their solution for roles and capabilities, I would probably continue to either use levels (where I needed a simple, quick hack). If I needed something more complex the way Zend Framework and phpBB solves it.
Interfaces
I'm used to torturing myself when developing user interfaces. What I've learned from WordPress is that it isn't a good idea to do so for your users. They want simple, easy and less steps. What we are fine with doing as developers of our own work, users only concern is just getting stuff done.
I think I'm taking that more to heart as I use more JavaScript (jQuery, etc) to develop user interfaces. I've found that you can go overboard and interfaces should still be developed for those who don't have JavaScript enabled. It is easier to work with JavaScript to give the interactivity of Flash for web sites, but all the features of HTML with regards to search engine support and mobile browsers.
Well, the study of User Interfaces is a whole another topic on to itself. There are jobs out there just for those who develop user interfaces and research and develop them. For me as a developer, it will continue to be something I research and study, but will never be my primary focus. I'm hoping to meet someone who can do that for me, eventually, or if the projects I work on start making a profit, I can hire someone to do it for me.
Installing
I used to take installing for granted. I'm not saying that I included them in all of my projects, because I don't. It is just that I was used to modifying configurations manually and setting up the tables and what not manually as well. Most of the projects I've used have always had a manual installation process.
I don't think that is as useful any more, because the best web applications out there, have automatic installation process for which you can configure when you setup and it will do everything to get the web application functioning for you.
For me, after seeing the many installation processes that exist, I don't think I'll ever develop an open source project that forced you into running SQL to create the table structures yourself. It isn't too difficult to implement something that does it for the user. Well, to be honest, the previous projects I've developed, the installation has always taken a backseat, because I didn't need it and given the time I had to work on the project, it just never got to the point where I could devote time to it.
I'm going to change that. It doesn't have to be difficult, nor does it have to hold your hand completely. Therefore, I've done it easily before. It was just a page you went to, that would do a few things to setup the application so that it was ready to run. It didn't take that long and while it isn't the best implementation, it works.
Conclusion
I think this is mainly why I'm not going to be developing patches for WordPress any more. I need to spread my wings and take flight and make my own mistakes. Working and fixing the problems within WordPress has been fun and a learning experience. I need to make my own mistakes and hopefully someone will come along and show me a better solution.
That is not to say that I won't go back to WordPress in the future, because I plan on it. I plan on taking what I've learned in my future open source projects and applying them back to WordPress. Hell, given the time it is going to take to finish the PBBG projects I have in store for myself, I think by the time I go back to writing WordPress patches, other problems and solutions will have found their way into WordPress.
So I'll like to thank the WordPress community for helping me and not kicking my ass when I was too harsh.