Forking Frog
25 posts,
16 voices
650 posts
|
Yes, you are reading this correctly. I’ve decided to fork the Frog CMS project. It is with some regret that I do this since I’m personally not fond of people forking projects. You can read the full announcement and reasons. In part, the reason for me forking the project is because of differences in opinion about the direction in which Frog should develop. I wish Philippe all the best with the Frog CMS project in the near and distant future, but for me the road ends here. |
536 posts
|
Well I’m sad to read that. I know that you done a lot for Frog and I wish you good with your fork! Anytime you want to get back on Frog let me know. I’m happy to have “work” with you :) |
12 posts
|
Thanks for all the help Martijn! |
486 posts
|
Well this is very sad news. If you don’t mind my asking, Philippe, what is the rationale for going back to 0.9.4? |
96 posts
|
Good luck with it, Martijn. The project goals and roadmap look great. And it already has the wiki that we’ve been waiting months for here! I’m sold! |
4 posts
|
Good luck Martijn! I will be keeping a close eye on your project and look forward to your progress! :) Brandon |
1493 posts
|
Of course it’s always sad to see small projects fork! But Philippe and Martijn are both talented developers, and hopefully this enriches people’s options, rather than diminishing them! |
184 posts
|
Not an easy thing for the Frog team I am sure. Like others have already said, the effort to date has been very much appreciated and surely will continue to be. Good luck to both Frog CMS and Wolf CMS. I will be keen to see how the visions evolve by version 1. |
343 posts
|
Hahaha DavidCOG . Good luck Martijn… |
20 posts
|
Very sad news, thank you for all your hard work Martijin, I’ll certainly be keeping an eye on Wolf CMS, looks very promising. |
48 posts
|
Why oh why Live long and prosper! (that goes for both CMS-s) |
109 posts
|
So who will be developing frog from here in and also why was the split taken out between backend and frontend if now it is going to be added back in? I will keep track of both projects. Martijn why not change the repo to github, this will make contributing easier. |
70 posts
|
Hello community, forking a project is never good —for both projects! But the biggest losers in that game are users using one project or the other. It will not last long and the plug-ins will not be interchangeable or bugfixes are not applied from one project to the other, etc. Also an additional project may split up the community and increases the chances that a project will someday be abandoned. No big deal for the developers, but for the users that deployed one project for their customers. All the design/coding/etc. effort spend must be spend again to support a new CMS. It always took some time to build a community that is supporting new users (as with this forum) and I’m not sure if Frog already reached its critical mass yet. I’m a developer myself for many years and I can understand Martijn. Sometimes you have the feeling that the development is going into the wrong direction and you can not agree to the point of the other person and how frustrating it is no to be honoured for the dedication. BUT that is the nature of man and there are ways to deal with it. ‘Leaving’ should always be the last option. I appreciate the contribution of Martijn and Philippe for the project but there are others, too. Maybe it’s not to late to bring them all back together on the table and talk this through. Maybe the project organization, workflow, and responsibilities must be changed. E.g. a core development team instead of a ‘leader’, change requests and a change control board, a project manager that handles the requested features and plans them for next milestones, a tester and/or coordinator, a documentation writer, etc. Sounds heavy, but I’m talking about roles not persons. The roles should be clear to every one and listed on the homepage. And to be realistic, a one-man development will never work. One can not do the development and do end-user support and having a day-job. So I appeal to Martijn and Philippe to talk about the issues. For preparation each of them should post their issues and point of view to this forum, so that the community is aware what this is all about and WHAT they want to talk about. I propose that there is someone who acts as a mediator or moderator if things get off technical (thinking loud about David?). At the end we should have a clear picture and decision everyone can live with. This creates confident for the developers (core and plug-ins) and users that already invested their time into this project. What do you think? PS: And believe me, I can create so much change requests for the core and plug-ins that there is enough work to do for all developers who want to contribute ;) |
|
486 posts
|
Good points, M. |
|
650 posts
|
I just wanted to reply to M’s fairly long post about the fork. Frog has largely been, in effect, a “one man development” from the very start. At first Philippe himself worked on Frog and versions 0.9.4 and 0.9.5 were mostly my doing. While I agree there should be a core development team, which is why I’ve always spoken about “the team” and “the Frog core”, it is my personal experience which leads me to believe there should generally be an overall architect/project lead/lead developer who has the final say-so. At least in smaller projects. I’ve been a developer myself for quite some time and have contributed to multiple open source projects. How you run a project depends very much on the project’s goals, size and how big you want it to be. The new Wolf CMS project I have begun is intended for me. That might sound strange, egotistical or whatever but that’s the heart of it. The idea was to protect my so far considerable investment in the code’s future. Having said that, it was always my intention to keep the code and its future available for anyone to use. I could have simply walked away from the project and continued development in private. Instead I have opted to share it and my time as an Open Source project. I agree that any project should have clearly defined roles and that is exactly my intention with Wolf CMS. Though it will most likely never be a big team, it is not my intention to “go it alone” for ever. My idea is to set a general direction, get the project going, recruit non-developer team members and then slowly build up a reliable team of 3-5 core developers with commit access. Besides the core development team, I hope to have an active user community who is willing to send in patches and bug fixes. Time is patient. ;-) As for plugin compatibility: you will be happy to know that version 0.5.0 of Wolf CMS is a one-on-one copy of Frog 0.9.5. Since I have guided Frog’s plugin related features in both 0.9.4 and 0.9.5, that trend of development will continue with Wolf CMS. While I won’t guarantee plugin compatibility between Wolf CMS 1.0 for example and Frog 0.9.5, at least in the near future, Frog plugins will happily run on Wolf CMS. As for the discussion you propose, that train has left the station. I would never have forked if I thought it preventable and discussions/exchanges of thought have taken place. While I appreciate that the users of Frog might want to have a say in all of this, my time is donated time. No disrespect intended here, but the users of Frog have absolutely nothing to say about how and where I spend my time. ;-) Anyway, what I’m trying to say is: I’m not changing my mind about the fork, I’m too far in. Give it some time and see how I structure the new project before deciding whether it will live or not. Keep an eye out on the wolf cms website. @easylancer – I think the Frog project has in effect ground to a halt. Sorry. I also think git is not the way to go. Again sorry. Creating patches against specific versions of a piece of software is not difficult at all and many developers have been doing so for quite some time. I have seen too many projects go down in flames due to too many developers with commit access “scratching their own itch”. :-) |
|
486 posts
|
Well thanks for having worked on Frog all this time, Martijn. I know you did a lot more than you had to. Best of luck with Wolf CMS. |
51 posts
|
I sad to read that too. I don’t like fork and all problems come with for the communauty. Someone can tell we what is the future for FrogCMS ? I use Frog for mulitple (small and medium) professional website, and as a developer, I need little more information to (perhaps) do a choice. |
8 posts
|
I too have the same questions as gido. Also, does front-end/back-end split mean that all of the html (design/structure) of the site are kept in external files and not the database? Nevertheless, frog (IMO) is still one of the top solutions for small to medium sites that require a cms. And I’m really great full for the time and energy that Martijn, philippe and others have put into this awesome app. Thanks! |
|
536 posts
|
To answer and give a quit overview of the next road map of Frog Cms, here is a little list:
a lot of this have already been experimented, but nothing enough flexible and stable to be use in prod :\ still open for ideas :) |
|
486 posts
|
Nice road map, Philippe. Looking forward to page part types! As well as support for plugins with front-end controllers. I’d also like to request that templates and snippets be automatically detected in the file system so we don’t have to use include for editing outside of the gui. Thanks. |
|
51 posts
|
Thanks for your answer philippe. I think so that have backend and frontend plugin is a must have. Same for multilingual features. Some more improvement ideas:
|
257 posts
|
I don’t quite understand the API evolution – if you reintroduce the split, you’ll need to have one plugin to manage the admin section of a plugin, and then another plugin in the front to facilitate showing content from that plugin. As far as my development goes, I wrote all the logic and views, and controllers for the back end in one plugin then that becomes available on the front thanks to the no-split… Or are you thinking of a different approach? |
|
536 posts
|
@ricks not sure too understand !! you meen removing snippet and layout from database ? @andy well split or no split version of frog … this is only 2 way to do the same thing !! and befoer the no-split version, plugins are available for both frontend and backend too, so maybe all this talk about the split and no-split is really not well understand by everyone. what I want to do is to load backend stuff that are need in the backend only and load frontend stoff that are need in the frontend only ( this is logical for me ) @gido links, images, videos … maybe the page part is not the good way to set those var, I have think about including “dynamic vars on page” they can be set in the layout and/or snippet then when you include one or other a new item is display in the page editing … or something like that !! |
|
51 posts
|
@philippe Just about the “split/no-split”: the good think about the “no-split” branches it that you can have access of your models class (which extend Record class) in the frontend features of your plugin. I think that’s is a not good pratice to have 2 versions of the Page class model (one for frontend, one for backend and which have same name!! It’s a bit confusing). But this is my opinion. Anyway I’m sure we can found an agreement (compris). |
|
536 posts
|
good point! but why you need to have access to save edit page, adding page part or function like that from the frontend ? |