Closed (fixed)
Project:
Omega
Version:
8.x-5.x-dev
Component:
Feature Request
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
5 May 2014 at 16:15 UTC
Updated:
9 Jul 2014 at 16:10 UTC
Jump to comment: Most recent
This issue will outline the current status of Omega 8.x-5.x and the remaining tasks for completion.
An initial version of the theme is currently added to the git repository under 8.x-5.x.
Once I've completed my notes, and added additional tickets for roadmap blockers, I'll update this ticket with the list/links.
Drupal 8 is getting closer, and Omega WILL be ready. Expect the same level of advanced configuration that you grew to love in Omega 7.x-3.x, or the ability to start with a blank slate with your own subtheme, and use the technologies you prefer.
Comments
Comment #1
fubhy commentedI've reverted the recent changes to the project page to mitigate some of the confusion. We will have to discuss this before any further action happens.
The publishing of the 8.x-5.x branch was in no way communicated with me and has since sparked a lot of confusion (as well as the announcements made by you on Twitter and elsewhere). Matt Smith and me have been maintaining Omega together ever since you fully disappeared about 2 years ago. We will gladly welcome you back on the Omega team if you want to make a re-appearance and collaborate with Matt and me but you can't just kick in the door like you just did. We've been maintaining the project without you for the past years and we certainly don't deserve this treatment. I did not revoke any of your project permissions, not even after 2 years of absence, but what you just did completely violated that trust and relationship. I wrote you a lengthy e-mail, explaining my worries and how I feel about this "event". To summarize: I am very disappointed and confused. Above all, however, it makes me sad to see this happening.
How can it be that, after maintaining this project for 3 years I (and also Matt, who joined me about a year ago), learn about your reunion with Omega from Twitter? How can it be that you think it is appropriate in any way to bluntly publish a new branch on a project that you have not been looking at for years and make changes to the project page, ripping out the logo that was carefully designed with all the love from Nico Grienauer and announcing the new release on Twitter and elsewhere? Doesn't that feel strange to you?
We have thousands of users relying on and working with Omega all around the globe maintaining small to large business and corporate sites who are following this project and the issue queue. Think about the confusion this has sparked. Maintaining such a large project comes with a responsibility on our side and it is *not* appropriate to toy with that responsibility in such a way. When learning about all this yesterday I decided to sleep over this whole situation before replying on this issue. However, due to the responsibility that we share with regard to our community and the Drupal community as a whole I feel that this needs to be discussed publicly.
Comment #2
msmithcti commentedI have to echo everything @fubhy has to say. After two years of absence to come in with absolutely no communication or discussion with those that are currently actively maintaining the project is a really disrespectful move. Especially when you have made it so public via Twitter.
Comment #3
dasjowhile many site building-driven themers will be happy to see the renaissance of the Omega UI, i'm also disappointed by the lack of communication with the current maintainers of the project.
Comment #4
schnitzel commentedOh wow. Really sad to see that happening. I was super confused when I saw the tweet. So I think there would have been definitely better ways to communicate and discuss that with the people that currently put all the work in Omega 4.
But let me rethink that:
Back in the times when Omega 3 came out, there was no SASS, no Compass, no overall understanding in the Themer Community how we build Responsive Sites. We worked with multiple CSS Files for the breakpoints and tried to get stuff done. At that point Omega came with something new: A Layout builder in the UI. Which made it super easy for SiteBuilders to build their own Responsive Site and still have control about the Breakpoints. So Themers and SuiteBuilders where happy. But the Theming Community evolved, we found better was to build Responsive Sites (SASS, Susy, Compass, you name it). And as Omega was maintained by Fubhy (a Themer), Omega 4 turned out how a Themer would like to have it: No Layout Builder in the UI, all done via SASS. Why? Because Themers know how SASS works, and they wanna have full control over everything. So Omega 4 was maybe not a Base Theme, it was more a Theming Framework for Drupal, which was great for Themers! But we left the Suitebuilders out. I talked to multiple people complaining about Omega 4, that it is not the tool anymore that they used to know from Omega 3. But there is no Sitebuilders to Blame, they don't wanna write custom SASS, they wanna have an easy system to build their Responsive Site, with some control about the Layout.
So now we are here, in front of Omega 5, and I guess the big Question is: Is Omega for Sitebuilders (with Layout UI) or is it for Themers (a Theming Framework). The responses on Twitter showed that some people really like what Jake showed: https://twitter.com/himerus/status/463367766511067137, so there is definitely need for the Layout UI.
I personally think we should have both. Probably the best way would be, that there is just a Layout Builder UI Module for Omega 5, which either can be enabled (for Sitebuilders) or not used at all (for Themers to have all the control). But I also think that this will be too hard, to much of a hazzle for two worlds to work with each other.
So here my proposal:
We fork away one part of it (not sure which one), give it another name, and make a big message on the Project page, that people realize that there are now two Themes, one for themers, one for sitebuilders.
Comment #5
himerus commentedFirst off, for those that know me, Hi! Great to see you again!
For those of you that don't, Hi! Great to meet you!
I'm Jake (himerus) and I've been using Drupal now for over 7 years, and a PHP developer for over 15. June 30th of this year will mark the 5 year anniversary of when I created the Omega theme in 2009, and awesomely enough, the 2nd anniversary of getting married to my wife! Didn't realize until yesterday those dates coincided!
Sebastian,
I do apologize for not taking the 'appropriate' steps in order to notify you of my plans for where Omega will be going in Drupal 8. I can completely understand your shock and why you would be upset. I guess I could complain that you've made this 'public' by hijacking this thread and deciding to have the conversation on Drupal.org, but since I pushed the 5.x dev version and posted on twitter publicly, I supposed I opened that door. So here is where the conversation will be had so that there are no confusions by you, me, or anyone in the community.
I understand you feel that you've put in so many hours on Omega and deserve better. I can say the same for myself.
I have two reasons for doing what I've done by flying under the radar with my plans for Drupal 8, and I will explain them now and perhaps you will then understand that those feelings of betrayal are mutual.
Issue 1: Hijacking a project
Point 1: Maintainership
Sebastian, since you came in and became a part of Omega 3.x, you have had FULL maintainer privelidges. I know you said that you were 'unable' somehow to add a maintainer, and that was your reason for 'taking over' the project page that now appears as if YOU actually CREATED Omega 5 years ago. I know now for a fact that this is completely untrue as I've had someone test adding a new maintainer after being given the 'administer maintainers' permission for the project. It was tested, and that person was able to give the new maintainer the same full priveledges if they chose to.
You say that your 'unability' to add a maintainer is the reason you had someone transfer ownership of the project page node to you, however, if this is your only reasoning, well, that is just simply false.
You could probably understand from my perspective how it appears that you want ALL the credit for the project for all time. I'll try not to quote emails you've written me about how you felt I got all the credit for Omega and you got nothing. I find it quite odd that the 'company' that you are CTO of seems to think that it CREATED Omega: https://drupal.org/node/2258511. It's sad that I can't count the times that I've read (on a page like that) or heard (via the grapevine) that you created Omega and I never get a mention.
Do you remember all those presentations I did at DrupalCons, camps, etc.?!? You ALWAYS had a place in my presentations on 3.x and I ALWAYS gave credit where credit was due in this project. Even when I showed this new 5.x last month at a local meetup group, I gave you mad props on the work you did making 3.x better when we worked as a team.
Point 2: Improper process for 'overtaking' a project
Here on Drupal.org, in most cases there are rules/guidelines/processes in place to make all of our lives easier.
When a project becomes 'abandoned' or unmaintained, there is a process in order to let someone else who was previously uninvolved (notice it says uninvolved, not a maintainer with full permissions already) take over a project and continue the contributions. This process can be found at: https://drupal.org/node/251466
When you took control of this project you did not follow ANY of these steps and I was NEVER notified of this change or requested change. There was no issue posted to the Webmasters issue queue that relate to the transfer of the project:
https://drupal.org/project/issues/webmasters?text=omega&status=All&prior...
I can only assume that you had someone (I think I know who) with the correct access on d.o. to "just" change the project for you outside of the bounds of the 'rules' that are in place. I never recieved an email through my drupal.org contact form, there is no mention in the webmasters issue queue as should be there, so I can ONLY assume that you did it in a sneaky way because you KNEW what you were doing was completely underhanded.
ALSO, please note that the above process is in place for ABANDONED projects. Omega was never, and will never be 'abandoned'. When I chose to take an undetermined amount of time away, the project had a full on developer (you) and at least 2 active contributors for documentation and support with all the appropriate permissions. So with that in mind, the above doesn't even really apply as it was NEVER abandoned, and you ALWAYS had full maintainer priveledges.
Simply put, your argument is invalid that you 'needed' to overtake the project because you couldn't do/change something.
Being a contributor in the Drupal community or in the Open Source community in general isn't about fame and glory. It's about building and contributing for the greater good. And if I was a huge glory hog I wouldn't have taken over a year away from the community to foucus on the really important things like family, taking a paying gig or two, etc.
In addition, being a contributor in the Drupal community isn't about doing whatever you want either, which brings me to my next point.
Issue 2: Project Direction
When I notified you, Chris and Joel that I'd definitely be taking some time off from Omega and the Drupal community, I essentially asked you for two things. I'll quote the email we exchanged on 2/7/13.
Omega was created to fill a need. It did that. The first version of Omega I created for Drupal 6, the 1.x, 2.x and 3.x versions I created for Drupal 7 all had the ability for those without a great understanding of theming or even Drupal in general to alter the layout for their site visually. Even if it started with a couple hundred dropdown select menus, it still filled the need, and by the usage numbers, it became clear that it filled a need people in the community, or new to the community wanted.
The first lines on the (current) project page says:
It appears that you care little for me, my original role as creator, maintainer, and for all those users that grew to love Omega. The changes you made to Omega 4.x could be compared to taking over the Views module and taking away the interface and saying that "People only want to have their views in code".
I've recieved countless emails asking me to come back and FIX this project, and put it back on the path it was. I've had countless people tell me they either still use 3.x or stopped using Omega because 4.x was NOT what Omega ever was. And as of this moment, it's time I acted.
You essentially, against my requests and against the needs of the Omega user base chose to essentially FORK Omega, and build whatever you wanted, and piggyback on the Omega name and YEARS of time Omega has been built up as one of the most reliable contributed themes on Drupal.org.
Conclusion & Resolution
Since it is very clear that we are at an impass on the direction Omega should take, I propose the following:
Now to the point of what theme moves where: Since Omega 6.x-1.x, 7.x-1.x, 7.x-2.x, 7.x-3.x and now 8.x-5.x will have a user interface true to the origins of Omega, and 7.x-4.x is the only outlier I'd think that the evolution of Omega 4.x into Drupal 8 is a logical point to create a new, separate project for that. The usage numbers for 7.x-3.x and 7.x-4.x also would reflect this.
Once again, I am truly sorry that it has come down to this, and I understand how you feel hurt, slighted, and marginalized. However, I think my points above should express how I've been left with those same feelings in the way you've treated both me, and Omega.
Now it's time to do what is right.
- Jake Strawn (himerus)
Comment #6
srjoshWhile I choose not to comment on the politics and personal issues in play here - which seem legion - I would like to say, again and publicly, what I have said at several camps and cons and in IRC: Omega's awesomeness lies in the interface-driven layout building.
I've been a believer in Omega since Drupal 6, using it (with himerus) on sites like http://www.maximumpc.com and http://www.maclife.com. I've given several well-received presentations at camps and DUGs (http://2012.badcamp.net/program/sessions/omega-download-layout-45-minutes, http://camp2013.drupalcr.org/en/session/omega-download-layout-45-min, http://www.phase2technology.com/blog/ready-set-go-spin-up-an-omega-layou...), including, at that last link, also writing it up for the Phase2 blog.
When I went to update that presentation - deliberately geared at site builders and drupal admins, and not developers - I was unable to do so. Completely. The tools which form the basis of the methodology I outlined simply do not exist in the 4.x branch, and a hinted add-on module never materialized. So that presentation got retired, and if a site builder asked me what base theme to use, I told them I didn't know.
The truth of it is that there are a number of good base themes for coding themers, but none for site builders.
Omega filled a niche which it has since abandoned. I found that disappointing.
I don't know, and don't care, about the whys and the wherefores and the personal politics of the issue; it's really not my place to comment on them and so I won't.
What I do care about is that there is now a possibility that I can answer that question again.
At the same time, fubhy and team have done an amazing amount of work on the 4.x branch, and there's no way we should allow that to be lost or minimize that accomplishment.
In light of that, I would recommend that a fork be generated, and the 4.x branch take on a new life under it's own branding and fubhy's ownership. We certainly have the technical tools to do so.
In short, I welcome the return of himerus and of site-builder-focused layout tools, and I also applaud the amazing amount of work and care which Omega has received from both Sebastian and Matt. I recommend you all find a way forward, as I believe that there is a need for and room for both directions - but maybe not in the same playground.
Comment #7
fubhy commentedI've done most of 3.x and 4.x was created and fully maintained by me and Matt and all we ever took credit for is Omega 4.x. I've updated the company page to be more specific. I find it strange that you think we were trying to hijack the project and not give you any credit. Especially since you mention that this is not about credit. Despite the right to do so, I never took credit for 3.x (or anything before), In fact we've always been talking about 4.x explicitly. Furthermore, your name still is and always was on the project page. Even ThemeGeeks has, and always had, a spot on the project page. The thing you are talking about is just the header of the node. What am I supposed to do about that? We didn't have access to add new maintainers and you have been absent for 2 years. You forgot to mention the e-mail we shared on January 21st, 2013 where I explicitly ask you to give me access to add new maintainers. You replied that I should already have access to do so... Well, I didn't. Following that we put your name on the page the very moment we changed the project page for 4.x and I made sure that it stayed there up to this point.
I already replied to #1 above. Regarding #2: The older 7.x versions of Omega date back to a time where a) responsive design was new to everyone (or didn't even exist yet) and b) viable module- and user interface-driven solutions for layout building and configuration didn't exist or were fundamentally broken. Out of blindness and ignorance we created a partly solution in the theme layer which was so limited and inflexible that the issue queue exploded with support and feature requests. The front-end landscape has changed since back then and it's not going to go back to where we were before. Time is moving forward - There is no way to change that. It is fundamentally wrong to expect a theme to be an all-in-one device that solves all site-building related tasks for you. Architecturally that's not even possible. Not even with the weird hacks that we brought to 3.x (yes, that's how I perceive 3.x these days). Omega 3.x was a performance nightmare and a huge maintainability problem. Trying to go back that route and pretend that we can solve the problem of a Layout interface in the *theme layer* is grossly negligent and short sighted. There are modules to fill that hole and even those can't solve the problem space satisfactorily. Why do you think all the "solutions" for this out there suck so much? That was a painful realization for me, but at least I did realize it and changed my mindset.
Omega had a couple hundred, maybe 2-3 thousands users when I came to assist with 3.x. 16.000 lines of code from me and 2800 lines of code from you later (yes, I just did a quick check on the facts) and, granted, a lot of marketing campaigning and speaking at conferences from you (which I am extremely thankful for btw.) we eventually reached 60.000 installs. On that grounds, how can you claim that I bad-willingly piggybacked on the Omega name? Are you really saying that, after two years of absence, you still are entitled to lock us into your vision of what the theme should look like? Do you see me as some kind of Project babysitter for when you are out of town? Following your guidelines and principles to eternity? Times have changed since 3.x and before. Front-end has changed. The technology is constantly moving. We took over when you left, and we kept it alive and made decisions that were necessary to keep up with these developments... And f*ck yeah, we did the best we could to do so.
Nay. We've taken necessary steps to build a framework that promotes modern tools and techniques that appeared on the market. This was the only way to show true responsibility towards the users of this theme. We've been active on the issue queue, on IRC, at conferences, etc. to assist people during the transition. We never removed Omega 3.x either. It was still there as a last resort. However, let me say this again: The niche that Omega filled "in the old days" no longer exists. I am actually not sure it ever existed. However, nowadays we have Panels, Panels Everywhere, Panopoly and all these tools that solve the problem you still think we are stuck in in a reliable and satisfying way. Hell, they solve it thousand fold better than Omega ever was and ever will be able to. This is a theme and not an egg-laying wool-milk-pig. That is, by the way, something very important I learned along the way.
Funny that you say it like this. I'd rather compare it to Drupal 7 => Drupal 8. Moving forward, dumping stupid homegrown, non-sustainable and antiquated methodologies and moving with the times. You know, staying on top and making well-founded and necessary decisions and getting things done.
Fully agreed... And it's about responsibility too. All this put together my understanding for your actions is further drifting away. Honestly, all that you are attacking me with in your post seems to rather reflect back to you. I am not buying your accusations. Most people still associate Omega with your name. I never had a serious issue with that. I never intended to change that. Are you blaming me for you being absent for 2 years? Because that right there is why people are starting to no longer associate you with Omega. Nothing else.
I gotta wrap this up now as I've got other obligations... I've no desire to fight about Omega. Especially not with you. Let me just express once more how very disappointed and sad I am about the way you have come back to the project. I whole-heartedly believe that you had no legitimation to do what you did here. You could've contacted me at any given time and we would've figured it out together. Again, I find it funny how you accuse me of piggybacking "your" theme, given that we reached the 60k installs in your absence, with only a fraction of the code at that time retraceable to you. To be honest, it rather feels like the opposite now. Again though: I am not going to have a fight over this. I don't have the desire, time or energy to do so.
Comment #8
himerus commentedI definitely won't continue or attempt to begin a flame war. That was never my intention, or the original purpose of this thread. I don't disagree that this wasn't handled in the best way by myself, but opening this conversation in this issue thread is only continuing the cycle. But at the same time, now it seems best that the community SEES this and reacts appropriately, however that may be, and whomever that may support.
I'll let the facts I posted above do the talking, including the manipulative way (outside of Drupal process) in which you 'gained' full control of the project. And I'm sorry, you are flat out wrong as you had permissions to add maintainers. There was no legitimate reason for your actions there. None. And if for some really, really odd reason, even with you having the 'administer maintainers' permission for the project, you were truly somehow unable to add additional maintainers, a simple request for me to add any and all additional contributors would have been taken care of.
I guess we'll let the community be the judge of this one... Your views and opinions, as well as my own no matter how correct they may seem to ourselves, cannot speak for everyone, so when it comes down to it, I guess the community should decide where this project goes.
And in regards to having a responsibility to the community and project, I couldn't agree more, and I feel like I have a responsibility and deep obligation to the Drupal community, and to those long standing fans of Omega to provide them the tools that they have come to know, love and use on a daily basis.
Comment #9
nmillin commentedI agree with srjosh’s comment (https://drupal.org/node/2259035#comment-8749821).
Omega is my sweet spot with Zen being too complex for my needs and AdaptiveTheme doesn’t allow enough flexibility. I have presented on how awesome Omega is multiple times at DrupalCampWI and WI DUG Meetups, but I haven’t been able to do so with the 4.x branch.
I have been recently perusing other themes to use because the 3.x branch, that is my sweet spot, hasn’t had a release since 2012-Feb-19. I tried to use the 4.x branch, but it isn’t for me. The 4.x branch seems like a completely different Theme to me. Before hearing about the 5.x branch; I was leaning towards going back to using Zen as a base theme.
As a site builder / themer, I am excited about the 5.x branch.
Comment #10
rggoode commentedI have been using Omega since before the release of Drupal 7, and it has become the essential foundation of every project that I work on. However, I am still building with Omega 3. I tried Omega 4 and found that it just wasn't made for me... It lacked the tools and user-friendliness that I'd come to depend on.
I'm a Site-Builder and a Designer, not a Developer. I wish I had the time to hone my skills and "graduate" to the elite rank of developer status. But that just isn't in the cards. So I need tools to simply get my work done and to deliver products that I can manage with my meager site-builder skills.
That's why I came to Omega... The heavy lifting was already managed in the framework, and I just needed to configure it to my ends. And it afforded me with options to do just about anything I would want... Without digging into code. And I imagine that I'm not alone in that. I believe that this ease-of-use model is what made Omega so popular in the first place.
Without getting into the mix of personal issues between the developers... I will simply say that I completely understand Jake's absence from the project... Omega is a contributed project, and life sometimes gets in the way. Bills need to be paid and, more importantly, partnerships nurtured. I'm just happy that--before Jake's "departure", a rock solid version of Omega 3 was in place that has allowed me to continue my own work.
With the release of Drupal 8 approaching, I was beginning to become nervous about what I would use going forward. So I am absolutely delighted to hear about the development of Omega 5 for D8. I was afraid I was going to be left out in the cold with all the other Site-Builders and grandmothers.
I completely agree with srjosh in post #6... the simplest solution—that I think works for everybody—is to fork the project. As it clearly changed direction and the focus was more toward developer/themers in version 4, I think that branch should assume a new identity and brand. Let both projects move forward independently and everybody is served... Most importantly, the community of users.
Comment #11
dasjoi want to add that i have worked closely with fubhy on creating omega 4.x from the end of 2011 to the first release by drupalcon munich 2012 and that there have been many attempts to contact you, himerus, to get in touch about the future of omega. it seems weird that after two years you come back and say hi here i am what did you do to my project when you actually had abandoned it for such a long time i think it is reasonable for your co-maintainers to continue their work.
on the other hand i agree with what schnitzel said: there are different assumptions & requirements and we can see from part of the feedback that many people wish for a site builder oriented omega to continue to exist. this could have happened as omega 3.x but nobody took care of doing so for the recent 2 years so only the front-end developer oriented 4.x was developed further and together with aurora, zen 5.x they have shaped the next generation of base themes for drupal.
it seems like a fork also on the namespace-level will be necessary to avoid further confusion for users, which is unfortunate, because both himerus and fubhy have put enourmous effort into the project. well this happens when we fail to communicate.
Comment #12
sethcohn commentedI'll just weigh in that I was around when Omega was only a twinkle in Jake's eye, and the ONE element he knew he wanted from the beginning, the way he described it all, the guiding factor, was the GUI. The initial versions of Omega (way before a release) all showed progress toward that goal. All of his presentations, all of his work, were about adding GUI controlled features to allow anyone to control the theming.
If Omega's changes in 4.0 have lost that focus, then they effectively forked the project at that point. Jake's absence (for personal reasons) might excuse that they did so within the construct of the project itself, but if the GUI isn't there, it's not "Omega".
It seem to me that the problem is solvable, with a fork, like most software maintainer issues... the real question is who gets the namespace, and who shifts to a new name?
If the new maintainers feel that 4.0's lack of a GUI, and change of focus toward code is a good thing, then pick a new name and allow Jake to keep the original intent of Omega, which defined it up till 3.0. Seems like courtesy to me, acknowledging the differences of opinion.
Jake's been very gracious in the past. I asked him a question about Omega 4.x some times ago, and he never bad mouthed the current maintainers, even as he lamented the problem. I'm glad to see he's taking the time/energy to bring Omega's vision back.
Comment #13
fubhy commentedYou keep saying that... However, I repeatedly stated that this was not the case. I even sent you an e-mail regarding the matter in which you claimed I already had the permission. Well, I didn't.
Common Jake... You've been gone for 2 years without a sign of life. You've always had the chance to intervene. Heck, I've even openly discussed the possibility of re-implementing the UI in a module that extends Omega. There was simply no interest and no movement at all to implement such a thing. That's what this was for: https://drupal.org/project/omega_ui. Nothing happened there. I fully understand that one needs a break every now and then. I don't have a problem with taking it slow for 2 years either. But you can't tell me that, if you are actually interested in Omega and feel a responsibility for it, that you can't spent 5 minutes to look at the issue queue (where we openly discussed the direction we would be going for) or join us in one of our Skype meetings or quickly chat on IRC or reply to an e-mail. I don't buy that.
That's not my intention either. I can't believe we are even having this dispute. I keep rubbing my eyes when I see this issue. Please, let's meet on Skype and talk about the next steps. I will be on Skype all day tomorrow. Just ping me whenever you have time and we can talk this through...
Comment #14
himerus commentedProper or not, since this problem was made public, seems it should continue that way until resolution so everyone can be privy to where and how this ends up. Again, I handled this situation incorrectly, there is no denying that, and now we both have.
There's also no denying you bypassed the 'process' outlined at https://drupal.org/node/251466 and (I can only assume) had a 'friend' just simply 'give' you full ownership of the project node. A dirty, underhanded betrayal of the trust I placed in you. If I had been gone 2 weeks, 2 months, or 2 years, that is simply unacceptable, and needs to be fixed.
If the process outlined in the linked node had been followed, I wouldn't have a leg to stand on, but I believe those kind of actions of disregard for following the rules by anyone for any reason do not have a place in the community. Just because you're 'good buddies' with someone with the appropriate administrative permissions on Drupal.org shouldn't give you the right to do something like this.
Omega 3.x for Drupal 7 currently has almost 60k (60,000) installs, and was, IS and still will be a VERY stable release that people do continue to use when presented with the option of 3x or 4x. I don't think bashing the most successful version of Omega is the way to go.
Again, for now I'll continue to let the community speak and continue to apologize that this is going/has gone down this path.
Comment #15
bladwin commentedΩ3.x was awesome with a UI for administering the layout of the (sub)theme. Ω4.x was equally awesome, although pretty much all of the clients I told I was going to use 4.x on their projects expressed to me that they wanted the end-client to be able to change the layout of their theme and requested Ω3.x as a solution -- I personally don't like that idea because then it's easier for the theme to break (when the end-client will not be receiving any Drupal specific training). As a theme developer, I absolutely love the fact that I can write code to get a layout done. I have however created some specialized Susy variable Sass files and documentation for clients that still want to be able to change their a specific layout. I've also been using the layouts feature of 4.x as a rudimentary "GUI" for changing region layouts, but that also requires that the client be able to express how they might want to change the layout.
In an effort to keep this short [and to avoid taking either of my friend's sides - 'cause I don't play that game]: Can't we keep all of the developer features of Ω4 (guard, bundler, sass, compass, etc) and implement the original "ooh-wee" [Omega UI] as a layout builder that works with the theme developer framework that has been the focus of the project over the last couple years? This way we can still cater to the "grandmas who build Drupal sites" [with a companion module, which shouldn't be a big ask, as the project was already in the works] and the competent theme developers [those of us who have been embracing cmd line tools for front end development since it became "a thing"] who have embraced Omega in its current state? This is open source, so if a fork happens, I'm sure that someone [maybe me, but could be anyone else. any volunteers?] will take both forks and merge them, if not for any other reason than "I like both versions, and they should be able to work together. If [insert GUI layout manager] is for administrators, why can't they simple modify the variables and other code I've written by enabling a layout module and doing exactly that?"
to be absolutely cliché: Can't we all get along?
Thank you to everyone who has been involved with the Omega theme, as I've been using it, and ONLY it as a base theme since it was first introduced in Drupal 6.
Comment #16
drupov commentedI am really sad to see this conversation happening and more important - where it is going. You people have helped so many of us - like me - with your volunteer work and I really don't think any of you has had any bad intentions along the way, whatever happened.
I wasn't aware of the differences until today and that's what wonders me most: Omega 4 has been here for a while now so this dispute should have happened the moment it was clear where version 4 was going, not now.
Now both sides are becoming loosers for ridiculous reasons and none deserves that.
Please stop posting here and get together in a more private environment to sort this out. There's a bit to talk about obviously. Fubhy made the first step at the end of #13. You've done such amazing work (together and not together), you are very smart people, you're gonna find the right words. And maybe inform us all here what the future of Omega is. That should do it.
And one more thing: http://flic.kr/p/bt9YzC
Cheers!
Comment #17
cellar door commentedWow - lots happens when you look away from the community for a few days! :) I hate to write posts that just say "me too" but I have to echo what Bladwin and Drupov say above as well as add in some of my own thoughts.
As someone who's been involved in the Omega project at various levels over the past 4+ years I can say it's not JUST a theme. I think anyone here would agree that Omega is a community that has evolved around a theme. It's become more than just code. Over and over again I've had people come up to me at camps and cons and say the community around Omega is what sets it apart from other themes. The fact that we have an IRC room where we'll literally build a site for someone (which we actually did a few years back for some poor soul that got in way too deep) is just an example of the community that's been built up around the theme.
When 3.x came around it did something new that no one else had gotten right yet - it gave the power to the masses to create a simple and responsive website. It was, and still is, great for anyone at any skill level to use. That universality had it's drawbacks though, which led to the stripped down lean mean framework that is 4.x. As 4.x grew up so did the technology around it (SASS/Compass, Breakpoint, Singularity, Susy etc.). It became a powerful tool that in the hands of a skilled developer could do anything anywhere with a logical workflow and handy tools. The pendulum had swung from GUI to cli. With it came a lot of frustration and abandonment from developers who had not yet learned the tools, didn't know how to use them, and didn't know where to start. We attempted to put documentation around it but it still didn't hit that sweet spot of usability for all.
I'm going to stay out of the politics (I feel like a kid watching mommy and daddy argue at the dinner table) and instead offer a hope that the pendulum can continue to swing back towards the center and do so without a forking of the code. I for one have been an advocate for getting a simple GUI in place so the inclusion of that in 8.x seems logical. Taking the powerful engine that Fubhy, Splatio and team built and putting on the GUI that Himerus knows how to do all so well would to many be the holy grail of themes. For 8.x having a theme such as this to start off would be a huge win for the community at large.
I know this isn't going to be an overnight process but I hate the idea that we fork not only the code but the community that has built this theme up to where it is. This theme thrives because it has some of the most talented minds in Drupal working together to build something that everyone can benefit from. The newcomers keep them humble and make them realize the areas for improvement and at the same time they are given talented mentors to learn from.
I for one think this is one of those situations where the rough time works out to create something a better than before. Lots of conversation around the future of Omega are to be had but let's have them together. Hell, in Austin anyone who's there and wants to talk about it over a beer the first round is on me!
Comment #18
pmelab commentedI don't want to comment on the way things were communicated, since everybody agrees that there have been mistakes on both sides. But I'd like to add my two cents concerning the technology-gap between 3.x and 4.x.
I've been using both versions of Omega, and I've worked on a couple 4.x based projects together with fubhy. And from my point of view the decision to get rid of the UI-Layout-Builder was right. The approach and technology around responsive websites changed dramatically since Omega 3.x, and having a responsive site layout is just the tip of the iceberg. And making people believe they can do "responsive website" without understanding how media queries work is dangerous. Over the last years I've had far to much clients that came with a nearly done responsive site, which turned out to be an unmaintainable mess because somebody didn't know what he or she was doing. The problem: clients don't know about Omega or Bootstrap or any other half-baked abstraction. For them another Drupal project failed. And the backfire hits all of us.
Simply doing another base theme instead of Omega 4 would have been the smoother way without annoying people that don't have the time or resources learn a new technology (*cough* Backdrop *cough*). But doing so would have left Drupal with a major base theme and a big amount of developers using the wrong approach for implementing responsive websites. Omega's momentum was an opportunity to teach a lot of people about of the right tools and therefore raise Drupal's frontend technology level as a whole.
Don't get me wrong. Abstraction is good, but for getting faster, not learning less. And IMHO, a sophisticated configurable panels layout plugin would be the right place for a responsive layout builder.
Comment #19
dasjojust for further reference, i'd like to add some references to the site-building driven layout approach that was proposed for D8 core during the Spark initiative:
Spark update: responsive layouts in Drupal
#1787634: [META] Decouple layouts from themes
#1813898: [META] Add editable responsive layouts to Drupal core
#1818142: [meta] Unified Blocks and Layouts (SCOTCH+WSCCI+Spark+Field UI)
#1816650: Add swappable (dynamic) grid systems to core
Layout module
Comment #20
cellar door commentedpmelab -
While I do agree with you that a failed Drupal project anywhere is a loss for the community I don't, however, think that providing a GUI to manage just a tip of the complex iceberg that is responsive design is what leads to failed projects. I've been part of quite a many recovery projects on failed Drupal projects and the common denominator among them all is a bad developer, not the tools. Even with the best tools a bad developer can create a mess. Part of what I think sets the Omega community apart is it's based around building best practices and helping developers of all skill levels create powerful themes.
I think what Omega 3.x did was create a solid base that beginners could get into and while they may not know what the media query is or how it effects things, they could create a well based responsive theme. Yes this opened the theme to the lower skilled developers and site-builders but as we've seen there are a lot out these people out there (we were all there too). By giving them a set of standards and best practices it allowed them to get their feet wet and learn responsive development at their own pace.
What 4.x excelled in, and really where I think the power in it lies, is it's a framework built around plugins. With 3.x you couldn't choose if you wanted the GUI or not, you were forced to use it and for the advanced developers this was frustrating at times. In 4.x you had layouts, development tools, libraries etc. that were all available (or removable) as the developer decided. This is a great way to build things, create a stable performance based platform and attach the tools you need to do the job correctly. This allowed the advanced developer to create a highly customized theme that was exactly what they needed and nothing more. In doing so though, we left out the ability for anyone to just pick up the theme and use it, the learning curve increased and turned away some people.
While there's great debate to have over where the various tools should live in 8.x (as dasjo pointed out there are initiatives to do some of it in core) the issue remains that we need to try and cater to all levels and that's where I think (read: hope) where 5.x is going. Let's build something that caters to all levels of developers providing best practices driven help to those who need it and gets out of the way of those who don't. The easier we make it for people to learn proper responsive design technique the less recovery projects we'll all have to do (and I know we all hate having to do those projects).
Comment #21
Kendall Totten commentedI've had people give Omega 3.x a really hard time for trying to build a GUI that as a result did not necessarily create the most performant site, or was "clunkier" than just doing everything in code. My response was, "There may be more advanced, better ways to do something, but at the end of the day not everyone has the time or the skills to use Sass, Compass, Susy or Singularity, Ruby Gems, Grunt, Bundler, etc etc on top of the already complex Drupal theming layer. Should they learn those things if they want to be a front-end ninja? Yes. Does everyone have the time to do so? No. Omega 3.x is a tool that helps those people at least get a site up and running that makes their content visible to mobile users. The users may have to wait a few seconds for it to load, but isn't that better than no site at all?"
I have been an Omega superfan from the beginning, first of 3.x and now of 4.x. I am one of your top evangelists. However, I do think it is a little silly that I have to tell people, "we use Omega! We used to use 3.x but now we use 4.x, which are different like night and day." It creates confusion when two vastly different things share the same name. It may have made more sense to fork way back when it became apparent that 3 & 4 were going in very different directions, but here we are, so I stand behind both Fuhby and Himerus as awesome people who just have different visions for the way things ought to be. And neither of you is wrong. If there's a name change in the future, we'll all help spread the word. :)
Comment #22
dddbbb commentedCrikey, this is weird. I'll keep it short:
Fork it if you have to - I'll follow the current codebase if it stays or if it moves.
I'm not interested in going back to the GUI. All of the major change from v3 to v4 was worth it and the right call IMO.
Comment #23
kyuubi commentedHello everyone,
As others said I'm not going to comment about the chain of events that led to this, if it was or not properly done.
What I am interested in is the direction of this project. I have been a Drupal developer for many years, frontend developer by trade and the technical director of one of the leading digital agencies in Sydney.
I understand the whole debate about UI vs Code. But as someone that uses the Omega framework to create responsive, enterprise level websites every day, I must say that Omega 3 was never suited for digital agencies in general. It's lack of flexibility and the overhead of all the UI was too much for any serious business that makes a living of creating professional websites.
Omega 4x is another story entirely, it was revolutionary, an essential tool that hundreds of companies use as one of the foundations for frontend development. It was won me and several others over to Omega's side, breaking the myth of "the bulky theme full of overhead" and changing into "the de facto, frontend framework for Drupal".
I respect both options but I have to say, and trust me I am not all alone in this, that if the Omega 3x style UI path is coming back, then you will loose our crowd.
I seriously hope that the work that has been done in the latest years continues, in the same stable and serious way that we are now accustomed too, and if that is now possible, I advocate for a fork of this project.
Thanks to ALL that have made this project possible.
Cheers to all,
Duarte
Comment #24
webstudiodelta commentedAs a full time Drupal dev/themer Omega 4 has come to replace Zen as my base theme thanks to it's excellent developer tools/library integrations and client friendly yet non-restrictive UI. I'd prefer that it remains as functional for me as it is now, especially considering some very particular clients demand it's use.
If the D8 version of Omega will return to a model intended for Grandmas I would follow along to the forked version or return to Zen.
Comment #25
cellar door commentedKyuubi/webstudiodelta -
I like you have grown to love 4.x's power and performance using it in all that I'm doing now. While the 4.x branch has gained a lot of traction among the enterprise and advanced themers, it's done so at the expense of those that aren't as advanced (which originally built up the base of Omega in 3.x).
I think there are 2 very distinct groups within Omega that each are passionate about the GUI/cli discussion and each have their very valid reasoning for it. What I'm trying to find is a common ground where we can create something that can support and manage both crowds. If we took the power of 4.x with it's plugins and the new 5.x GUI as just another plugin layer it would give the option that users could either use it or disable it depending on their needs (like how the layouts and developer tools are now). In my opinion the best way the forward without a fork (which I'd hate to see a project like this get forked) is something along these lines. Where we create an environment for both types of users. We have skilled developers passionate about both sides of the coin so there's no reason we can't all work together to make it happen.
Bladwin and I discussed on IRC today about having a BOF in Austin (and/or more around food/drinks later) to discuss the feasibility of this and get a sense of what tools are needed from the various users. I would love to get more discussion of this going as I think it's something that's been brewing in the Omega community for a while that's now coming to the forefront.
Comment #26
tim.plunkettRegardless of how this thread progresses, and regardless of whatever happened previously, the project owner for Omega should not change without an issue in https://drupal.org/project/issues/search/webmasters.
Please open an issue there without any bias or accusations, and this issue can continue on in whatever direction you see fit.
Comment #27
kyuubi commentedCellar Door like I said I totally understand.
I must be honest when I say that having Omega fill both roles is going to be a hard challenge, and I am afraid the cost will be the quality of the framework.
I too do not wish the project to be forked, but even if you don't and we keep going in both directions under the Omega flag, I think it makes sense to have 2 separate builds, one for each purpose.
Trying to wrap everything into a single theme can become difficult to accomplish and manage, but then again that is not my place to say.
I totally understand the frustration of some users for the lack of UI, as I hope they understand ours, if the UI comes back. In the end if we can find the way to work under the same project, keep the quality and please both crowds, that will be obviously the ideal scenario and one that I think everyone will support.
Thanks for sharing this issue with the community,
Cheers,
Comment #28
fubhy commentedJake has now opened an issue for that at https://drupal.org/node/2261455. Any further discussion related to that matter should be held there while the direction of the project itself should be discussed here.
Comment #29
Dale Baldwin commentedYeah this thing needs to get forked and fast.
I'm guessing I'm not the only one but Omega 4 is at the core of what I do on a daily basis and has been for over a year now. Without it I'm screwed and can not imagine going back to the 3 branch and all the limitations and performance issues it brought with it. If any of that were to come back in 5 that for me would kill Omega.
I get that there is a part of the community that either can't or won't progress past learning old school CSS but in trying to cater to that market you risk the project being able to cater to developers or pro themers (what ever you want to call us).
on a side note aren't the templating and GUI features being implemented in D8 anyway? Why do we need them implemented a second time in the theme layer?
At this point if this is the discussion we're seeing can we fork the 4 branch (Omega Pro?) so that those of us who rely on it for paying the rent have some sense of security returned.
Comment #30
fubhy commentedBoth me and Matt tend towards moving somewhere else too... There are multiple profound, technical reasons as well as the now present personal issues that are going to make maintaining this theme in the future very problematic. In addition to that there will always be the bitter taste resulting from this dispute that I have no desire to deal with. We are either talking about a fork or a collaboration with one of the other major themes for D8. Some of you may know that there have been numerous discussions with some of the other theme maintainers at and around DrupalCons / -Camps and that we've been working together and borrowing ideas and code from each other for a long time now. Maybe this whole situation is actually a chance to dramatically improve the Drupal front-end landscape for D8 and initiate an even more thorough collaboration in this area and potentially even a joint effort. I already informed some of the other maintainers during the past couple of days and will talk with the rest when I get the chance to... We've already started to work on a sub-theming framework for D8 and are bursting with ideas, so... whatever this may lead to, Matt and me will continue to work together and follow the direction that lead to 4.x and will, in fact, even expand on that.
I hope that this comment just did that...
Comment #31
serg2 commentedThank you Fubhy, I really needed to hear that.
Comment #32
dddbbb commented@fubhy That sounds very promising. Fewer similar base themes and more collaboration can only be a good thing. Every cloud...
Can this particular conversation be made available online or is it currently restricted to meets at camps/cons?
Also, how will this affect v4 for D7 in the short term? Business as usual? Or is it going to get less love due to a possible shift in focus (D8, forking, etc) and the nothing-short-of-chaotic re-introduction of an old/new maintainer with completely different ideas. Can we ensure stability for v4 for those of us relying on it in the meantime?
Comment #33
fubhy commentedYes, we can assure stability of 4.x for D7.
Comment #34
Dale Baldwin commentedI guess next question is will there be a port in line with the features and model of 4.x for D8? If so when can we see it as it's the only reason I haven't started building in 8 yet.
Comment #35
msmithcti commentedTo reiterate what @fubhy said, we will be continuing our work in some form, although that is increasingly looking like it may not be under the Omega name. I personally want to ensure there is continuation of the ideas from Omega 4 in Drupal 8, so whatever form that takes I can guarantee it will exist.
As for the future of Omega 4 if we were to move elsewhere, we will ensure something remains maintained (if relatively minimally as focus will be on the Drupal 8 version) as we both use it commercially on a daily basis. For the users, this would ideally happen on the Omega project so updating is as seamless as possible, although that may not be feasible.
Hopefully that allays some of the fears raised above :)
Comment #36
dman commentedTwo things :
1. As a d.o moderator, I can confirm that there were sometimes circumstances where a project administrator who was not an original owner could *not* in turn manage additional members - whether they had the project admin box ticked or not. Something was broken. This may not be the case today - since the 7.x upgrade, and it may not have been *always* the case on older versions, or there may have been other special circumstances that made it work for some accounts and not others. I'd seen it as just a d.o glitch that had a work-around so wasn't worth digging into.
In short: I have seen cases where the only or most obvious way to let someone manage users was to just give them node ownership of the project. Given that this was simply practical, and the project admins concerned were usually in agreement, and all it meant apart from that was a different username showing up somewhere - it's a purely pragmatic maintenance toggle that has happened before now without an 'abandoned project' waiting period - not a conspiracy-theory coup.
2. I've been a huge fan of both Omega3 and Omega4 - for different reasons.
I loved Omega3 because it gave me a base that just did responsive right out of the box.
! feared Omega4 due to the new technologies and the re-learning required, but accepted that the Omega3 UI was trying to do too many things and couldn't do so safely unless the user *already* had an understanding of breakpoints and the underlying maths, and that the new approach was an improved rationalization of an idea that Omega3 was a prototype for.
But I have always said and swore, Omega4 should have been a new project. It vitally needed a new namespace.
We are building re-usable distributions, that began using Omega3 and built sub-themes from it.
Now we are upgrading our base distributions for new projects, that are wanting to use Omega4.
But this plays hell with the upgrade paths of our older projects, because a subtheme of omega3 and a subtheme of omega4 are totally incompatible due to them both being called 'omega' etc...
I think Omega4 should have been a new namespace from the start so I think that a proper fork is probably the best thing for everyone.
Comment #37
pdjohnson commentedHi,
There is not denying that between Jake, Seb and Matt all have contributed a huge effort in achieving all versions of Omega. With so many installs live, great care and consideration should be taken in reaching an outcome here.
The approaches taken with Omega 3.x and Omega 4.x are poles apart. Both serve different use cases well. I have to concur with the sentiment of others ...
I always had in the back of my mind that it was quite radical how different 3.x and 4.x were. Both Seb and Matt have established strong reputations in the community and gained respect of their peers. IMO starting a new project following on from 4.x as a fork will attract as much interest and loyal following in Drupal 8 as if they retained the Omega name. In having 2 projects, both approaches can flourish, co-existing is going to prove challenging both technically and philosophically. Conflict is never good, we should reach resolution and pour energy into code not politics.
CTI Digital (the Drupal agency I run and Matt works for) are heavily invested to Omega 4.x. We are committed (and have a vested interest) to assuring the viability of the theme. Like many others, we depend upon it commercially. It will be supported. We are also keen to see the progression of the approach taken in 4.x forward and expanded upon in Drupal 8.
I look forward to seeing a positive outcome from this discussion.
Comment #38
kyuubi commentedThanks guys,
Good news indeed.
Comment #39
cellar door commentedAm I the only one with the notion that this can continue on as a single project? How does having a core layer and an optional GUI layer detract from how anyone uses the theme? Political differences aside, if we are a community that is focused on building tools and providing them to others what good does it do to split it up and diverge the talented coding and support omega has flourished under? If anything Drupal needs more convergent projects and less divergent ones, as Fubhy said this is already happening with some of the theming layer in D8.
These are just a few of the questions I am left with after reading all the comments. As someone who's been working to co-lead the support and documentation of Omega since 3.x I can't tell the numerous times we have had to walk through and get someone setup on 4.x that just didn't get it, and not all are newcomers. I use 4.x in all my company does I see and understand the need for stability in the platform. I get that, I agree with it. But as a power user I don't agree with the idea that the theme would be utterly ruined on apocalyptic proportions if a GUI was provided as an optional layer for those who need it. The need to create powerful frameworks and a simple to use and understand GUI aren't mutually exclusive.
4.x did a great job in catering to the power user but in the community I have heard NUMEROUS times from different levels of developers that a simpler way to interact with it was needed. Why not use 8.x as a platform to do just that?
Comment #40
dddbbb commented@Cellar Door - It's a fair point but I'd be concerned that resources that could be more in my interest as a "power user" were being spent on developing a GUI that I'm never going to use. I'd also be concerned about GUI development blocking the progress of other features due to incompatibility, conflicting viewpoints, slow/bad decision making or whatever else.
In an ideal world, the theme would be all things to all men (and women) with no drawbacks as a result. The bugger is, we don't live in that world.
Comment #41
dasjohow would you envision those two approaches being blended together / integrated on top of each other?
i'm not up to speed with php-sass compilers and how well they play with theme developer tools. the idea of controlling parts of the css through the UI was also appealing to me, but in the end i gave up on it because ruby sass was just developing too fast for the php compilers, but that was two years ago
Comment #42
fubhy commentedNo. PHPSass is a red flag for me and a huge no-go. Same with the GUI. A module for that? On top of a port of page manager? Sure. In the theme? No way. Its oncredibly hard to get such a GUI right. It's hard to get it to perform well and even harder to make it usable. Doing it in the theme in a way that leads to a satisfactory result? Impossible.
Comment #43
himerus commentedIt appears that based on replies here, a fork of the two projects is in order and forthcoming. I’ll leave this reply as the basis of my opinions on the future direction for the Omega project.
Since I began using Drupal over 7 years ago, one of the first terms/phrases that I learned was the insane ‘learning curve’ that Drupal had. Luckily I had many years of PHP behind me, had worked on, in futile attempts, to create my own home grown CMS. Then Drupal was introduced to me, and did ALL those things that I needed and used on every project. Drupal came easy to me. Since then I’ve never looked back, and Drupal has accounted for 99% of the work I’ve done since, including over the near two years I’ve not directly participated in the Drupal community.
The Dreaded Drupal Learning Curve
Unlike myself and many of those that have commented on this thread, most Drupal users, new and old alike are not elite coders and simply never will be or will choose to be. The majority of Drupal users chose to USE Drupal to solve a goal. The majority of users never contribute to Drupal core (myself included). The majority of users have a specific goal in mind when deciding to use Drupal. The majority of users fight against the dreaded ‘Drupal Learning Curve’ and solving those issues and barriers to adoption has long been a sticking point, and focus of the community.
From http://www.acquia.com/blog/problem-drupal-learning-curve by Heather James
From http://www.tsvenson.com/blog/2012/08/unblocking-the-drupal-learning-curve by Thomas Svenson
With those comments in mind, let us think about the tools we build for the community and how they impact those users. The above thoughts and quotes directly related to why Omega was created to begin with. When a new, potentially non-programmer type comes over to try Drupal, what do they get? Well, first they get all those great features they always wanted like a blog and a contact form and all the core goodies that make Drupal what it is and keep us from reinventing the wheel on every project. Cool huh?! It’s why we are all here.
Now assume that new user is able to get Drupal installed locally or in a hosting environment following some of the great instructions available out there from those of us Drupalers that have done it before and shared the results and methods. Awesome!! That user can start whacking out pages and blocks and menus and creating ‘something’ that met their needs in regards to functionality. Back in the day, that new site was all wrapped into a Garland theme that we still see way too many remnants of across the internet. Today in Drupal 7, they get to look at Bartik out of the box which made improvements in both code and visual appearance. But like Garland, and like ANY theme that is ever introduced as the default theme when installing Drupal, Bartik is now just an obvious visual flag that says “Hey there!!! I’m a really vanilla Drupal site!!”
Next, let’s figure out what a new user will do to change that theme. Historically, they would browse to the listing of contributed themes, and pick out Marinelli (https://drupal.org/project/marinelli) or one of the other themes that you could just enable and ‘make it pretty’. Now, let’s throw in those new users that actually DO know just a little bit of CSS and really want to make a theme look unique for the site they intend to build. Zen (https://drupal.org/project/zen) has been around since the dawn of time it seems like, and provides a great base theme that allows someone with the proper knowledge to do whatever they want to visually style their subtheme. Zen was the first base theme I tried myself after building out a handful of custom themes.
What didn’t exist when I created Omega was a theme that allowed a user to really change the layout of their site without touching (or understanding) a line of code. Much like Views made complex SQL queries easy, Omega opened a door to users that had a minimal understanding of CSS and more importantly LAYOUT CSS and best practices of how to “move this sidebar over there and make it bigger”. In Drupal 7, after the 6.x version was ported to Drupal 7, then ‘improved upon’ a tiny (very tiny) bit in 2.x, Omega 3.x introduced responsive theming to the masses. It introduced Responsive to those users in a way that made it so very easy to ‘do it’ without completely understanding why. Most users, I repeat, MOST users never care how or why it worked.
That being said, Omega has from the very onset filled that gap that in some way helped lower the barrier to controlling the layout of a Drupal site to even the most inexperienced users. That is where it began, that is where it flourished, and that is where it will continue. I’ll throw out some *made up* numbers here to help visualize that a bit: Assume 1000 new users attempt to use Drupal each week. Of those 1000 users, let’s assume approximately 10% of those users consider themselves at least ‘decent’ and front end stuff like CSS and JS. Now let’s assume again that of that 10% (100 users) only 10% of those users consider themselves advanced front end developers that user all the latest whiz-bangs and all the ‘right’ ways to do things. That brings us to 10 of 1000 new users that week in Drupal that needed something to help them on the path to their goal of creating a website and having some way at all to change the layout of that site a bit. Simply changing course for those 10 new elite users is unacceptable. What about the other 990?? When they try out a few things, and nothing works, nothing helps them get any closer, they get frustrated, they delete their installation, and we never see them return to Drupal again.
In order to demonstrate the above in a bit more *factual* way, I will break down some numbers on Omega usage.
In total current numbers (as of April 27, 2014) compared between Omega 7.x-3.x and Omega 7.x-4.x show the following:
“Okay, fine, but that’s not fair because Omega 3.x has been around longer!!!” Indeed. So let me attempt to break this down in another way. The following numbers show the adoption numbers for Omega 3.x and 4.x in the first year following the alpha1 release of each. The numbers reflect the total usage for all versions that were made available during that year.
Omega 3.x
Omega 4.x
Now we could argue again for hours on if these numbers are biased in some way, and that’s not what I’m encouraging. What these numbers show, in my honest opinion, is that Omega 4.x missed the boat by alienating those imaginary 990 users I mentioned above, and only gave those other 10 what they wanted and needed.
That does NOT mean that Omega 4.x hasn’t done amazing things and as is obvious, HAS gained traction and adoption, even if lower and at a slower rate.
Conclusion
We could all argue until there's no air left in the room about what technology is best, which method is 'right' and in the end none of that matters. What matters is fostering and nurturing the Drupal community, and helping introduce new users to Drupal, and continue to grow that community. To me, the above usage stats are a slap in the face and I can't find a way to argue with them.
All this said, it is clear in my mind the direction that Omega 5 should and will take. And just because it will again return to roots and focus on making it easy for ANY user to pick up and use doesn’t mean that the code behind it won’t be performant or ‘good for themers’.
Are there better ways to do things since 3.x was released? Yep.
Are those things going to be considered in 5.x? Yep.
Do I intend to continue to make creating responsive layouts for beginners easy? Yep.
Do I hope some of you do and will share that vision with me yet again? Yep.
Thank you. Please discuss.
Comment #44
scotwith1tI miss the GUI. While I'd love to learn and master SASS and all the accompanying tech that the "new" Omega utilizes, I simply don't have the time and I think a fork that pulls the v4 out into its own project is completely reasonable. Let's face it, while it obviously borrows a bunch from v3, it's practically a completely new theme anyway, at the very least a completely new approach. +1 for the fork so folks can make the GUI v. SASS-and-company choice for themselves.
Comment #45
cellar door commentedSad and hopeful. Those are my two feelings right now. Let me explain:
Sad:
@danbohea not to call you out directly but you're the only one to say exactly what many people here were meant in their postings
This unfortunately is at heart the issue with this entire discussion (and sadly growing within the Drupal community as a whole). When I look at the community built up around Omega and where it's come from since 2.x when I first installed it (and learned the Drupal theming system because of) it's built up on the shoulders of everyone looking out for the common good. As we wrote the documentation for 3.x we did so actively inviting newcomers and those who've never opened up a php file before to help us make sure we made them approachable and made the theory of media queries and css available to the masses when it was just starting off.
The concern over what "I" can benefit from is in direct disagreement with the concept of "we" benefitting as a community. As Jake outlined above, Omega was never about "I" it was and is about "we". When we realize that we all too were once new to the technology and had to get some help from those who were already skilled, we realize that the same helping hand that was given to us needs to be reached back for those behind us as well. Sadly, the focus of the advanced group of Omega users has skewed more towards how to make the platform better for them without realizing how they got there. Yes there is benefit from creating some high powered tools that fit a very specific niche in our work. But I would argue that there is as much or more benefit in creating tools that give everyone a chance to create a better site. Otherwise people who try and fail and shoot themselves in the foot will give not only themselves but the Drupal community at whole a bad name as yet another recovery project is needed to save the site.
Its because of all this that I'm sad to see things where they are. Instead of working together in collaboration for what could benefit everyone, we are splitting the community, the code, and the skills behind it.
Hopeful:
It'd be a lie to say this hasn't left a bad taste in my mouth but by nature I'm an optimist. I'm hopeful that what comes of this is better than what came before. I'm hopeful that as Drupal continues to grow and mature into the powerful platform it is, that we can do so making it approachable for all skill levels. More-so I'm hopeful that from this we can continue to work together as individuals towards that common goal, maybe now with just a little more focus, and continue to share ideas and techniques to better the respective platforms.
To answer the technical questions from above: No I'm not advocating for PHPSass and never will. Anyone who knows me and has heard me talk at meet-ups and camps etc. knows that I'm as big an advocate as anyone for the adoption of the Sass platform within the Drupal community. What I envisioned was a tool that would help tame the steep learning curve that it takes to create world-class sites using Sass/Compass/Singularity/Breakpoint or (should they choose) giving them the option to not use it at all. In all honesty that's the major piece in 4.x that is missing and that has lead to the drop-off in adoption. Looking at the stats shows just this (I'm a scientist at heart so data speaks loud to me): https://drupal.org/project/usage/omega you can see that since March 22nd 3.x has lost roughly 3500 installs while 4.x has gained 600 (rough numbers not taking in account those that upgraded earlier 4.x versions). Why are there 5x more people leaving the platform when they move from 3.x to their next theme? It's because our focus has been too narrow, or the skill level too high. If 4.x had the same approachability that 3.x did, I would argue, we wouldn't see 80% of our users leaving the platform. Creating the GUI as a layer that sits on and a core that can easily work with/without is what will make a powerful 8.x theme regardless of what name is attached to it.
I want to, and will continue to be, involved in anything that can help continue to push the theming community forward as a whole and I look forward to working with you all to make that happen!
Comment #46
dddbbb commentedStarting to feel like I should never have waded in now. Damn you community!
@Cellar Door - I'm sorry you're sad. My comment wasn't intended to come across as selfish. My concern is that spreading resources across even more features, many of which will not benefit all of the project's users (advanced or beginner), especially at this stage, just doesn't sound like a great idea. If anything, that's the opposite of selfish and very much more concerned with "we" rather than "I". I only used the term "power user" to make it relevant to your comment ( end of public character defence despite not technically being called out ;) ).
Yes the stats are dropping off, yes it's directly related to a shift in focus, yes it's more niche now, yes the learning curve is higher.
Is any of that bad? No. There is a demand for this end of things too, it's just not as large and that's hardly surprising. But that doesn't mean it's bad - it's just different.
Don't get me wrong, I do appreciate what Omega 3 did in terms of introducing me to responsive concepts as well as saving me some time. There are other themes that fill that gap now - it's not like people don't have options (and it sounds like they''ll be getting another one soon). But it's a little late in the game to begrudge more advanced users for defending the features & flexibility they're interested in given where the project's already gone and why. It's not sad that they're now more concerned with these more advanced techniques or concepts - if anything that's a great thing - Omega 4 taught them that, they're grateful and now they're building even more awesome stuff - of course they're going to want to protect that.
Comment #47
topplestack commentedThis saddens me by the way this was handled. Jake, you have/had two awesome theme developers that you had an opportunity to work with. I'm sure you will fond other great developers who will work with you in the future, but know that the ideas between these two have been great. It would have been awesome to see what the 3 of you could have worked out.
I'm not a very strong PHP coder and I have only been working with Drupal for 2 years. I don't have a huge pedigree of experience and am honestly not very good with PHP, but I am with CSS, SASS, and HTML. I am completely self taught and work in an office where I am the sole site developer. I have learned a lot of things the hard way.
I will admit, there was a lot more of a learning curve with 4.x than 3.x. Looking at it from a theme perspective in general, 4.x was the vastly superior theme. Doing things from the command line was a bit of a pain, but necessary. Documentation could have been a lot better. The thing is, I cannot see the 5.x branch without what Sebastian and Matt have added.
Comment #48
GuyRus commentedThis was handled terribly.
The support and dedication of Seb and Matt over the last few years of Omega has, from my personal experience been mind-blowingly awesome. I firmly believe Omega is one of the best maintained projects on Drupal.org. Seb has personally helped me on more than one occasion which I'll forever be thankful for!
I've shipped about 10 projects in O3 and 10 in O4 and as a "themer" I think 4 is in a completely different league. When I started with O3, I thought the UI config was pretty cool but based on my experience gained since then (and eventual frustration with 3), I don't think the theme layer is any place for a configurable UI as Seb previously mentioned.
Branching this is going to suck but I think is necessary moving forward.
Comment #49
muntjac commentedWhat reprehensible behaviour. This is not how Drupal developers conduct themselves: milking others efforts for two years before gazumping them. The current maintainers' stewardship has been brilliant and I hope they know how greatly appreciated they are. It's become an excellent theme. Wherever the project fork finds it's home, it will be successful.
Returning to this project, I suggest that in future the top question in every Omega user's mind should be, how likely is Jake Strawn to swan off again and abandon his project? Because whenever he's next gripped by an irresistible urge to speak at conferences for two years, I can't see there being many people keen to look after it for him.
Comment #50
meichr commentedHeya muntjac, the second paragraph of #49 wasn't really productive, don't ya think?
What is needed now, is a most cooperative way of all maintainers to minimize the impact on the future of both Omega projects. No need to hit on anybody of them. I happily remember the marriage proposal Himerus made at DrupalCon London, live during his session. Don't ya think, some outtime is appropriate for founding a family? If I read correctly, that seems also to have been communicated between the maintainers more or less.
Anyway. The obstacle for a fork of Omega 4 is big, as its promotion of state-of-the-art theming is also benefitting from its being second in the theme list due to the high number of installations, mostly of Omega 3. A fork with about 8000 installations, which Omega 4 has as of today, would be at position 20 of the theme list, way more "hidden" than it is now. This is an obstacle to be overcome. Fubhy and Matt deserve to not be let down, with their great work on Omega 4 (and Fubhy's big contributions to Omega 3). At the same time Himerus' philosophy of having a sitebuilder's base theme with a UI seems to fulfill a big demand. I used Omega 3 for some projects without much time and money to create and at the same time love the much better flexibility of Omega 4 for other projects.
If we can't have Omega 3 and 4 (or 5 and 6 for the next Drupal generation) in the same project, and I agree that the seperation of the two philosophies into two different projects should finally be resolved, then give a fork of Omega 4 (I liked the suggestion of Omega Pro) great linkage, every help possible and the necessary information on the original Omega project page.
I also like Fubhy's hinting of merging it to one of the big current themes (Zen ?), though an upgrade path would greatly be appreaciated, the letdown from Omega 3 to 4.
Comment #51
dman commentedYes @muntjac,
So far we have managed to discuss this serious disagreement politely, and everyone is looking forward to a practical resolution to the issues raised.
Lets keep personal attacks out of this in this thread and look to what can be achieved instead.
Thanks.
Comment #52
macmladen commentedThere are some strange things here and I will use no more than one paragraph to express my opinion: every emotional issue here is plainly wrong as it is wrong to argue on transfer procedure. Even if someone wishes to make a "trial" that may happen in #2261455: Ownership of Omega project. so I will say "please" no more on that one. Everyone. Jake and Sebastian parted their ways and we all have to accept that reality. Please, no hard feelings, do not be sad or hopeful, this is not a place for that. There is a good rationale for separation and I see that as a good opportunity as Sebastian pointed out to improve even further.
Today there are many interesting UI configurable responsive base themes like Adaptive theme, Arctica, Fusion, TB Nukleus, Zurb Foundation, Bamboo and really many more that have a lot of options in UI, are interesting, user friendly and operational. And new are appearing like Naken, Malinis so there is really no need to worry about site builders being left out. Even in 2011 when Omega 3.x appeared in August, already in October Arctica was out offering full responsive in UI control of breakpoints. Also did Adaptive theme in version 7.x-2.x from September same year. So it was not unique to Omega 3. Also both Arctica and Adaptive theme have been active and continue to live to this day.
Although there are a lot of overlapping in Zen, Aurora, Omega 4.x, Adaptive theme (to name a few and many more excellent themes out there) there is a lot of space for all of them to exist and for their authors (and future ones) to bring new paradigms and shifts.
Without diversity, we would never progress so wherever some author believes there is a space for improvement (or decide not to develop and embrace other) that is a good thing.
From the start I wished Sebastian did took other name as Omega was already is other mindset but I didn't care too much about the name as I also do not care now (a.k.a "couldn't care less") - it is the project itself (code, philosophy) that matters.
So let's get real (and pragmatic) and see what can be done.
As I suggested in #2261455: Ownership of Omega project. I think Jake should retain Omega and lead it his way and I'd like to see Sebastian pick a name for his project and continue life on its own with Omega 4.x replicated code (or not) as I suggested there and only if that makes sense for all involved. For me personally, I do not care for naming or location, both me or any developer being capable of using Omega 4.x will find it and will know how to handle upgrades, with Jakes help or without.
Sebastian, I do not think you should merge with any project. Your base is too strong to be retrofitted to any project and really there is no need for it. Everyone will be free to base their own theme on it just like there is Adaptive theme and Sky, Pixture Reloaded and Corola. At 8.000 installs it is a serious project and merging with some other will bring trouble to both parties. Besides, why would you want to do that? Even if you do want for some reason, Omega 4.x should be left as it is, both on Omega project (please Jake I know you will be sensible to keep it there where it is) and (if) under new project.
Preserve it in same form so it can be upgraded without effort or minimal and backport anything you will develop for your Drupal 8.x version if that doesn't break things. D8 version will live its' own life so it can be as different as you like.
I hope this helps and also I hope for a friendly resolution for both of you as you will meet on some Camps and will speak on Drupal, theming so please be mature and do the right thing after these misunderstandings - they are really unimportant for the future of Drupal and all of us.
Comment #53
Tran commentedHimerus makes themes/modules I can use -- as a journalist running a community news website. Himerus is reducing obstacles for web publishers while Omega 4 seems to increase obstacles and moves Drupal toward the "Pay to play" internet.
I don't really care who names what. Drupal needs the Himerus model of Omega unless Drupal wants to get out of the average-joe Internet business.
I'm a journalist who has enough trouble with Drupal as it is. but I've learned enough to operate my site and build a couple websites for organizations like the fire department, etc.
That said -- Himerus disappeared and left a lot of people in the lurch without any information. I had great hope for Nodemaker and themegeeks, but nothing materialized and no communication was made to users. This shouldn't change the way we think about the overall issue I suppose.
Comment #54
fubhy commented@Tran: Noone denies that Drupal needs UI-backed tools. I am sure many people agree that there should be contrib tools to allow absolute non-developers to get something out of Drupal. However, as I've argued many times before in this issue: It can't be solved in the theme layer. Not even close. Both conceptually and architecturally. Trust me, I've been there and learnt it the hard way. Not only is it programmatically infeasible to get this to a satisfactory state within the theme layer... it's also a dead-end. If such a solution is to be implemented, at least implement it properly and in the right place.
Comment #55
mrpauldriver commentedOh dear oh dear! How did we ever get here?
I like Omega 3 and even though it is showing it's age, I still use it today. Omega 3 gives me all that I need to make sense of Drupal's complicated theme stuff, let alone the ability to produce responsive websites which continue to wow all my clients. And let's be clear about this, Omega 3 was doing responsive, long before responsive became mainstream. Omega 3 got me into Drupal and I'm so glad that it did! And yes, I guess you could call me a grandma, but I bet I am not the only one around here.
I now understand that Omega 3 is a bit clumsy and bloated; but right from the beginning I have been intimidated and overwhelmed by Omega 4 and I still wonder whether I might be better off joining the masses and learning something more mainstream like Twitter Bootstrap instead.
Only today I've been forcing myself to download all the Omega 4 dependencies again, torturing myself with the command line stuff and re-watching the hangout videos, some of which I participated in first time around. Does it really need to be this hard?
Lets face it, Omega 4 was a huge departure from Omega 3 and personal opinions aside, we are now where we are!
I personally have stuck with Omega not only because I'm familiar with it, but also because many said that graphical UI sub-modules for Omega 4 would come along sooner or later. As Sebastian says above, contrib modules are probably the right approach, but so far such modules have not materialised, although I hope that they still will.
I'm with Cellar Door on this and really hope that some understanding between the maintainers can be found. Given the Darwinian nature of so much that is Drupal, why can Omega not become the fittest survivor? One theme to stand above them them all and an ecosystem in it's own right.
Comment #56
karolus commentedThis is indeed unfortunate...
I learned Drupal theming using 3.x, and admittedly, 4.x was a major challenge at first, but I feel I'm well rewarded by the learning investment I was forced to make.
Nonetheless, I see why the fissures have formed, but this could have been handled much better than it has.
Sebastian is probably correct that the UI could be supplied by contrib modules, and I agree with him that the theme layer isn't the place for the UI, especially with the code overhead that this process generates.
Hopefully, there will be a productive resolution to this, for the good of the community overall, not to mention some projects currently in the pipeline.
Comment #57
lakshminp commented@Tran: Couldn't agree with you more. Drupal needs to be more end user friendly. I was a big fan of Omega 3 myself and later defected to Omega 4 and never regretted that move. Let me explain why.
Lot of effort is being made by Drupal developers to make Drupal easier to use for non developers. Omega 4 sits in the sweet spot between flexibility for themers and Drag Drop style UI for site builders. It facilitates this ease of use all the more by offering integration with layouts and panels. Omega 3 essentially reinvents the whole thing and as a side effect, limits a lot of themers in terms of the flexibility it offers.
Regarding your "Pay to Play" comment, even if Omega 3 gives you the ability to create your own site layout, one can only go thus far and eventually will have to resort to a themer to write the CSS and do trivial stuff, like exporting configuration, setting up etc.
Omega 4 has honestly made the life of themers a lot easier, especially if you come from the panels school. I really hope you find peace with Omega 4.
Comment #58
jacobson commentedWe are all witnessing the end of Omega.
Comment #59
chandeepkhosa commentedPlease guys - peace, tranquility & understanding ... the love that brought us together was Drupal. Let's not spoil it with a public squabble, we are all adults.
I hope we all find a way to co-exist and keep on contributing to the amazing projects of Drupal & Omega.
An aside - Omega 3 was my favourite Drupal theme of all until Omega 4 came along which I am getting to grips with. I appreciate that it is helping me to become a better developer by getting me a tiny bit outside of my comfort zone, but what's stopping us from having Omega 4 also implementable in code and the UI as a choice depending on what you prefer?.
You sometimes have a development team of people with different skills, not exclusive environments of the site builder / interface guy & the coder guy, especially when different elements of projects are done ... sometimes with big gaps.
You want the interface to be easy to setup by a site builder who may want to delegate some theming work at a later date once a majority of blocks have been assigned to the different sections.
Just my 2 cents as a 6 year long Drupal site builder who is transitioning into a full all rounder back-end & front-end dude.
Comment #60
Enno commented@Chandeep: Love did not bring me here. Money did. The money (I am talking my man hours) that I saved for having an efficient, modern base theme in Drupal. In my case that is Omega 4. I understand that other people would make the same argument for Omega 3 based on their skill set.
I don't think we need peace or tranquility, exactly because we are all adults. We just need some decisions and understanding from the project owners to move on.
Personally, as an independent developer, who is highly dependent on the Omega theme and especially fubhy's work on it, I would hope for answers to the following questions:
I perfectly understand, if the questions above cannot be answered yet and I don't want to come over as impatient. I am just a bit worried for not knowing if I can continue to use my favorite theme.
Comment #61
grienauerjust my 2 cents...
As a designer I really used and liked omega 3 a lot.
When I was first "forced" to use omega 4 I thought this will not work for me... but now I fell in love and like it really a lot to work with Omega 4, sass, compass and the other magic things around :)
I did the Omega 4 logo and so I would prefer the Omega namespace should be for Omega4 ...but now I end my thoughts with a meme ;)
Comment #62
drupov commented@Grienauer LOL!
I see I am not the only one who started with Omega 3 and enjoyed it but ended being absolutely delighted that Omega 4 came out and what it brought to the table in terms of useful tools, which are an abolute must if you want to be well positioned as a modern frontend dev.
And there is some misunderstanding to some in terms that Omega 4 is about writing code and not suitable to people which are not used to coding. Of course there are some things to learn, but also enough ressources, so the most important parts should be out of the way in a meaningful period of time. Soon you will see that your Omega 4 theme integrates wonderfully with those mighty layout tools which we have in Drupal 7 - e.g. the whole "Panels Universe". And that should close the circle for those not willing to do coding, because Panels can do a lot and is integrated in lots of places.
Now if a think about Omega I mean always Omega 4. For other it will be different.
So why should one prevail at all? Omega 4 for D8 goes to the Khan project, the same could/should happen to Omega 3, it can live in a new namespace in Drupal 8. That would be the fairest solution in my eyes. And the omega project page would link to both with some meaningful explanation.
Comment #63
pfaocleI propose the name "Omegerd" for the forked project.
Comment #64
leon kessler commentedOmega 4 surely has the momentum, being the latest version.
I'm sorry but egos should really be put aside here. If you want to go back to omega 3 than that is a new project. Doesn't matter if you started it or whatever, it's the point of colloboration and a group of people moving forward in one direction.
Comment #66
gstout commentedI'd like to toss in my two cents. I was also around a received help from Jake with Omega in it's first year.
Regardless of how feelings may have been bruised or a lot of circumstantial comments, Drupal has a process for taking over projects and that process wasn't followed.
That process exists to protect all Drupal contributors, to encourage them to dedicate time and effort to creating great projects by letting them own those works into the future. If he had left and abandoned Drupal we could follow the proper process as defined by this community and return his code to the Drupal eco system. Jake has not left the Drupal community. His creative work, and time should be protected and should belong to him.
If we abandon these principles them how will we grow a community? How will we become all that we can?
Greg
Comment #67
cellar door commentedIf anyone would like to talk about this thread, where we go from here as a theme and as a community let me know. BOF board filled up quickly but think a good discussion is to be had. If there's interest we can do an ad-hoc BOF or meet up at one of the parties to discuss more.
Look forward to seeing everyone here at the con! If you see me say hi, would live to meet you.
Comment #68
Dale Baldwin commentedHey I just want to thank you guys for putting me on a new path as of late that I think will completely unshackle my skills from Drupal front end dev and give me some possibilities I never thought of.
Two things happened recently that got me moving. Firstly this cluster fuck pretty much exposed the dangers and limitations of Drupal's theme frameworks and how overly reliant I was both in where my skills are or were and also my reliance in what is essentially a single technology stack to do my work.
The second was discussions about how Angular JS could be used with Drupal. Throw in recent advances with the services module and I had to start asking myself do I even need a Drupal theme at all! So I signed up to do some online courses to learn JS (my js knowledge up until recently was in the context of jQuery only) and angular and am now exploring the immense possibilities that brings.
So props to you guys, you opened my eyes to SASS and the possibilities that lay there and now through this total fubar mess you opened my eyes to angular and the power that lies in a Drupal back end and an Angular front end.
Comment #69
rggoode commentedI couldn't agree more with Seth in comment#12... Simple solution--emotions aside--just fork the project and move on. The name Omega should remain with it's origins as created by Jake. Whatever the name of the new 4x project... It's a different animal, and should exist on it's own.
Everybody wins... GUI. For thems that wants it or needs it. And developer version for the people that prefer that.
If an unsettled, dissatisfied feeling of "ownership" remains... Perhaps that part of the argument can be resolved by the numbers... Which fork ends up with the most users.
But for me, I'll be happy to have the choice, and forget the rest.
Comment #70
slipperysky commentedAs much as I'd like to, I don't contribute enough to drupal, and my posts are meager at best....but it's hard to believe what I stumbled upon in here (and in the other thread on this). I thought I should at least mention my experience with Omega.
First, if I repeat something someone said above this, I apologize. I probably wont, but I wanted to say that. I don't have the time to read this whole thread right now all in one sitting.
I started using Omega maybe about 6 months before 4.x was released. I thought Omega 3 was great but when 4.x was released, I was excited to see all the dev tools I wanted to use integrated into the theme. It seems there were other themes starting to do this but not to the extent of Omega 4.x. I was also glad the interface items were taken out. Actually, I didn't use the 3.x UI stuff often so it didn't matter much. I already have enough of the interface to deal with in Drupal and in the multitude of incredible modules. UI is obviously valuable for making some complex elements within Drupal a lot easier to manage, but for the theme, I mostly want to be typing. The theme interface of Omega 4.x was perfect for me. Then the added sass and all the other tools along with it were exactly what I needed. I may not be a brilliant developer but it's pretty easy for me to install rbenv, ruby and all the necessary gems into my Manjaro/AwesomeWM machine. I had already installed Ruby because I wanted to learn it anyway (still haven't). Honestly, Omega 4.x has helped me learn things that I may not have decided to learn and it's driven me to improve all the necessary front-end skills I was wanting to improve. It was more than a theme. I was installing it just to use it as a tool for practice and learning.
After all this has happened though, would there be an Omega 4.x if there was no Omega 3.x? I have much respect for Omega 3.x, what it stood for, but am also thankful for how it has somehow in its own way led to Omega 4.x. It appears that events happen, decisions are made, people live their lives and we go on our ways. It was meant to be this way, was it not? I'm not implying one version is better than the other. They are what they are and you just choose the tools you prefer to use.
I just hope both sides can find a way to come to an understanding and not hold onto any hard feelings in the future. We should all know life is too short for that.
Comment #71
kattekrab commentedHi all,
Someone has anonymously reported this issue to the Community Working Group (CWG). After reviewing this whole thread, it would seem to me, as chair of the CWG that this is largely a technical issue, and should instead be resolved by the Technical Working Group (TWG) IF it can’t be resolved directly between Fubhy and Himerus..
I would draw your attention to our freshly minted Conflict resolution policy which outlines the followng 3 steps.
From the comments it seems as though there are very different positions, and a fork is one possible outcome here, but that is not something that the CWG is empowered to decide.
Cheers
Donna
Comment #72
dddbbb commentedSo, where are we at with this now?
I missed DrupalCon Austin and subsequently any BOF or social chats around the subject that have not been fed back into this thread. Are we any closer to a resolution?
Comment #73
j.am commentedI believe the issue was resolved and omega 3 and 4 will stay as they are for drupal 7, with omega 7.x-3.x and 7.x-4.x continuing to share the omega project space and issue queue. Going forward into drupal 8, omega 8.x-5.x (himerus branch) will remain in the omega project space, and omega 8.x-4.x (8.x-6.x? - fubhy branch) will be in a new project space khan.
Comment #74
himerus commentedWhen this node was created, it was meant to be a roadmap for 8.x-5.x (still visible in initial description) and where I planed to take my version of the project that is rightfully mine. In the first comment, the thread was hijacked, and the thread is now what it is.
It would seem that the "resolution" to the direction of the project "has" been agreed upon: https://www.drupal.org/node/2261455#comment-8796513
In response to #71, the primary, and FIRST issue is that this project ownership was taken without my permission as PROJECT OWNER. I think that would be a good candidate for an issue for the CWG. I had been contemplating filing a claim there myself, but hadn't yet since the form was ridiculously long! The actual issue of direction of the project/location of the projects/branches is a side product of the project ownership issue.
I wish someone from the CWG would address the edit to the Omega project that happened on September 24, 2013 - 14:51 by sdboyer
Comment #75
fubhy commentedYou are getting "your" *cough* project "back" after not maintaining, hell, not looking at it for years while all your other projects were left unmaintained destined to rod in dust half-done on d.o as well without any notice other than empty claims ... and btw. I already agreed to withdraw. What else do you want? Are you really going to drag Sam into this now and unleash Sherlock Holmes or sth.? Please take a deep breath for a moment and think about it and then just take your loot (literally) and be done already. There's been enough damage.
Comment #76
himerus commentedHere's a fun fact for you... These numbers can be checked here: https://www.drupal.org/project/usage/omega
June 8th Usage Update
Omega 4.x: 7,343
Omega 3.x: 59,949
June 15th Usage Update
Omega 4.x: 7,585
Omega 3.x: 60,381
If you do the math, in the last week, Omega 4.x had 242 installs, and Omega 3.x had 432 installs.
You can keep *coughing", but again, the numbers don't lie... this project that I "abandoned" according to you, and my version that hasn't had a new release in 2 years still gets more installs than your fancy developer version. You can do the math for the last several updates, and most of them still favor 3.x.
Keep arguing about how your version is awesome, and how I abandoned the project, it just keeps making you look like a child.
The numbers back me up (clearly) and so does the process of project ownership and the fact you stole the project ownership without my permission which you admitted to here: https://www.drupal.org/node/2261455#comment-8756429
What else do I want?? I want the project back that you stole. Period. Yes, since it was Sam that you convinced to change the node for you, it's about time it's mentioned since nothing seems to being done except you yapping your jaw.
LOL. Keep it up dude. Can't wait to see you again! *hugz*
Comment #77
fubhy commentedStole? I didn't follow the right protocol because I was stupid enough to think that you would be reasonable about and because we struggled with permissions. The only reason why we are even having this discussion is the fact that I did not follow the official protocol. Other than that, you would, as stated by you, have "no leg to stand on" (quote end). You left it rod, like so many of your other projects. You failed your responsibilities... But fine... I made a huge mistake by not following the protocol and I agreed to withdraw and hand it back to you. Can we please be done with this now?
First of all, how is this relevant for this discussion and secondly: Didn't we already look at the facts and figured out that your involvement with 3.x (at least in terms of code) was minimal to put it lightly?
Really... Just to make this clear once more: The version you are talking about was *not* written by you. Your involvement with the code written for 3.x was minimal.
... I am really tired of this whole pointing fingers at each other though and would really prefer to be done with that already.
And you are getting it back as stated multiple times now.
I really hope that's not a threat. It sure sounds like one...
I can't stress enough how disappointed I am. It didn't have to come to this. Unlike you I've always been around for the past years, months and weeks and it would've been easy to contact me at any given point in time and we would've figured it out. It makes me very sad to see this development here... I am not sure how to deescalate it though tbh because of the continous barking.
Comment #78
himerus commentedTry not to forget, you escalated this in comment #1 here on this thread.
Back to comment #71:
The only reason my contribution as you put it was "minimal" for 3.x is because every morning I woke up, you had rewritten ALL your code again from scratch. I think Chris and Joel will gladly remember that fact too.
How about you stop complaining about me taking personal time off since that is none of your #$@#$ business.
YOU are the one that abandoned this project by COMPLETELY snubbing the user base and creating something wildly off the wall different.
YOU should have left this project a LONG time ago...
Comment #79
fubhy commentedNo, I did not file anything.
It's not, no question. You have all the right in the world to do that as I stated multiple times. The way you did it is what I am complaining about.
Hah, thanks. Your wish is my command or sth. :P - I am already on my way out the door as stated multiple times.
Comment #80
fubhy commentedJust for clarity: I kept proposing that we meet on the phone/skype/hangout. I still think that it would've been a good idea to actually talk about this instead of throwing poop at each other. Call me naive if you will but I am sure that that would've shut down this discussion weeks ago.
Comment #81
dddbbb commentedStatistics & pride. Yawn...
Back to progress, reliability and all that's good, see you at Kahn. Happy to help get this **** back on track.
This is easily the biggest knock on Drupal I've witnessed so far. So glad this is forked now.
@himerus All that time you saved me back in the Omega 3 days (thanks btw), I reckon I just wasted it all again on this thread.
Comment #82
danny englanderIn light of all that has happened here it would be great to get some kind of statement as to the future of Omega 4.x for Drupal 7. I am a new Omega 4.x user within the past few weeks and loving it but I'm hesitant to invest time and effort developing with it if the future is unclear. I am asking as I saw in this related issue, (#2261455: Ownership of Omega project.), written by fubhy:
@danbohea - I don't think this is forked, the new project called Kahn is for Drupal 8 only as far as I understand it.
Comment #83
drupov commentedWordpress dev to a Drupal dev: "Our CMS still gets more installs than your fancy developer CMS". :)
But seriously, Omega 3 was convenient and helpful, but through Omega 4 I learnt so many invaluable things about modern Frontend Development and it is paying off already. But it costs time and willingness to learn all this new stuff. I totally understand guys sticking with 3.x beacause of that and that should explain install numbers.
I think this thread should be finally closed.
Comment #84
damienmckennaIn the interest of decency and putting a stop to the arguing, can we have this issue locked please?
Comment #85
himerus commented/agree
The primary issue of project ownership has been resolved, and any further discussion related to the direction of future versions of Omega will be made available in an appropriate meta issue.
Comment #86
tim.plunkettLocked.
Comment #87
tim.plunkettFixed and locked, I should say.