Services module fork

Matt,

hi there. I was a Services module developer, but due some differences in the approach with other developers, i decided to fork it. It's intended to be my own private module, but i decided to share with all other people my code.

Web Services module and Services differences are:
* WS uses the standard OAuth authentication system, the same as Google, Facebook, Yahoo! and Microsoft. S uses a custom home made keys system.
* WS will support, out of the box, SOAP, REST, JSON and XML-RPC servers. S has a buildin XMLRPC server and rely on 3rd party modules for other servers.
* WS will have 25+ services. S has less than 15.
* WS consumes about 60% less memory than S.

Bottom line. Its the Services module with 250+ commits on it.

regards,

massa

This is a fork of services module. Forks are by no means at all allowed in the Drupal repositories.

Well, maybe discouraged. However, brmassa has a very long trail of forks ( one that I could find quick is http://groups.drupal.org/node/10237 but some of us seem to remember an ec fork ecommerce plus maybe?), commit accesses revoked and such. While I really appreciate his hard work, I would vote on his cvs access revoked.

Oh, and http://groups.drupal.org/node/4258 asks "why do you fork potx module"

Yes, forks are discouraged, unless there is a good reason for them.

The fork of ec was justified at the time by porting the module (don't know details, don't know if gordon was consulted/informed on the matter or not, so the picture is incomplete for me on this).

Before we revoke anyone's access, we should

1. notify them of the issue (I guess brmassa is following this thread, so he is notified by now)
2. hear their reasons on they did this (he already listed some points, I will leave it to others to see if they are valid or not)
3. ask them to talk to the maintainers of the original module and see what they also say. Perhaps we should invite Rob Loach and maintainers of Services to chip in with opinions.

If there is no good reason, and this is a repeat then there should be a warning, then revocation after that.

This is a sticky issue. I've seen brmassa do a lot of good work on various projects and in various issue queues and I know at least one developer who has been grateful for what was a significant amount of help. I'll let that developer speak for himself.

That being said, it seems to me there's something of a cloud of conflict following brmassa around. My feeling is that it's too soon to vote on any permanent action (I'm referring to comment #3). A temporary suspension may be in order but I say that knowing that I'm not the one to make that decision. Let's discuss.

ps. eCommerce Plus is gone but it is mentioned on groups.drupal.org at http://groups.drupal.org/node/11599

Guy,

i just read this issue because Services' maintainer, Scott Nelson, sent me an email. Im plain chocked.

Im a businessman, graduated in Business. I own a software company and I only program when there is no option out there on marketing. Despite the fact I always considered fork a natural process on OS, i only publish my own forks because i believe it will help people. I will use them anyway. The point is: will anyone else be able too? All my modules that are forks started from simple set of new features and became real different options.

Yes. I forked many projects:
* SlideShow Creator (from Konstantin's Slideshow): the original module uses a node type for uploading images and buildind a slide show. My module uses a filter or CCK to insert slideshows directly.
* Addresses (from Location). Addresses focus on physical addresses-only (useful for e-commerce solutions) for users and node thru CCK and a API for external integration such as maps and custom display, while Locations include geocoding and has a very limited API. Addresses has 65kb and Locations is a 1500kb module.
* Live Subproducts (from e-Commerce 3's Subproduct): while the original module calculate all combinations at once (it might create thousands/millions of new nodes), my module only creates new combinations when needed. Also, uses other nodes as the source of the combination, instead a custom made "attribute". The solution was so better that was incorporated on eC4, replacing the old code.
* Live Translations (from PotX?): its not a real fork, since i only used a modified code on the first drafts of another bigger module. It was much better solution that including patch and a long and complex INTALL section for testers. All modifications would be integrated on PotX later (in fact, at that time, PotX had no version for D5). The module was a big part of Gabor's GSoC project, so i was happy to let him finish it and change the way he wanted. He renamed the module to "L10N Server".
* e-Commerce PLUS: ahahaha i told on the description was only a temporary project, destined to host a D6 port. Gordon, the eC maintainer, doesnt like much about opening new branches, so i decided to host the temp files elsewhere, but using a version controller.
* Web Services (from Services). Despite the given set of new features listed, im now incorporating 2 new APIs and about 30% of the services were revamped.

I ALWAYS tried to be a dev member from original modules first. I used to commit several patches a day. I used to address long dated issues in matter of days. And only when i find no solution (or when i have an important time constrain), i start a fork. I always include a "If possible, i would love to merge both projects in the future" statement because i simply hate to maintain a fork. Its costy and a pain in the ass. But from all modules im the lead maintainer (13), there is no more than 10 issues, from support, bugs and features requested. I really believe the developer-user relationship is important, even when telling them "Man, i dont know how to fix it." or "postponed: I will fix it when i get some time. I will love if someone create a patch.".

I know forks are discouraged. What i didnt know is that is almost forbidden. For me, its like the Drupal coding standards. Wanted, not required. Well, if you require so, i can use another project hosting service, such as Launchpad or SourceForge and post here a note only. I think its far less powerful, but will work.

So, Im really hurt about Károly's vote for revoking my CVS access.

regards,

massa

@brmassa

Forks are not a natural process in Open Source, they fragment the efforts on a project and confuse the uses. It is a last resort thing with all other options are not feasible.

Before any of this forks, did you talk to the maintainer of the module and offer to submit a patch for their project so that your features are incorporated into the main module?

This should be the first thing to try: "I like the module, but need feature X, Y and Z, and don't like the design because of A, B, and C. So, I am working on a patch to correct this. Will you accept it? I can even be a co-maintainer if you like and help with the issue queue".

This happened a lot in my modules, and I am happy to have co-maintainers who will move the modules forward when they need to.

@kbahey: he stated in his defence that he contacted the authors and worked with the standard processes as much as he was allowed.

@all: I have seen several instances (I won't name names, but can if necessary) where a module developer was not considered inactive and a module was not considered abandoned, but the author did not communicate with the users or others who offered to help in the way of patches and co-maintainership.

It's very frustrating. One cannot be expected to hold up projects just because a module's author does not communicate with those who are attempting to get things done and are interested in helping out. That was why I created the Basic webmail module.

I don't personally have any reason to defend or attack brmassa, but I certainly understand and can sympathize with his situation.

This is a pointless hijacked thread about a general Open Source and GPL issue which will never be solved here and it's not fair to point all the heat at one person. I have been forked (http://www.phpnuke.org/) and have forked others (http://drupal.org/project/bookmarks2). Forking happens.

@brmassa, try not to fork if you can, otherwise, thank you for sharing your work. As part of the original issue, perhaps it would be helpful to expand on the availability of documentation (handbook, README.txt, project page, etc.) so others can more easily find a comparison between the two modules.

@brmassa - what's wrong with maintaining your own forked version off of drupal.org, and contributing back patches?

Wow, many replies. I just created a Launchpad project to host all these modules before i see this.

@Khalid

I believe that splitting and merging are part of the process on Open Source. Linux, Gnome are OpenOffice are projects that forked the effort, but not the code, while Safari's and Chrome's WebKit is a real code split from Konqueror's KHTML and vTiger is a SugarCRM's. I not only asked to by a co-maintainer, but i did several commits on each projects. The problem is when i need to give a real step forward: i have some needs (and deadlines) that people dont see or dont want. At this point only i think about a secondary project.

@Matt

Thanks. Yes, its common to see me and my projects on top on http://drupal.org/cvs, but it might be misleading. I use CVS like i use Bazaar: i commit "per code change" instead "per feature". I commit always, all time, keeping a detailed history of my changes and motives. On Bazaar, i can have a local branch and only commit on the "official" branch when the feature is done, but its not possible using CVS. But i like to think that im working hard on getting things done.

@Jason

Thanks for your comments. Its a common thing. I have a similar problem on eC module, which im already a co-maintainer. Gordon is much more slow paced on developing than I. We scheduled the eC4 to November 2007 and hes yet not convinced to release the code (for D5). Since i need a D6 version, i had to start a temp parallel project.

@David

Thanks you. Im planning to create several documentation and tutorials (and i was already writing some), but i need first to finish the code. There is no released version nor a big announcement and all code is still on HEAD. I dont even know how you guys found it :)!

@Dmitri

There is not wrong. As i said, the only reason i maintain here on d.o is because other people might need it to fix the same problems. I can maintain it for myself or publishing it on an external host service, but its simply not as good. Its becoming harder and harder to only commit patches: the code is now with a lot of changes and its not practical to split them in patches. I created new files and deleted others, moved a lot of functions to other files, there is a new hook, 3 new attributes for each services and a new world-wide standard authentication process and all this in 3 weeks. Meanwhile, the original module had only 5 commits, and all of them to revert my code, when i was working there. Im not sure i can create individual patches now...

@all

I propose to keep this Web Services module a low profile (well, i dont know much how) and WHEN and IF it comes ready, i decide if i announce and a fork or break it entirely into patches and populate the issues list. Otherwise, if you guys really think that it wont be enough, i can really move the code to another place. I can fully understand the reasons, but i cannot agree with some of them.

best regards,

massa

Since this issue has been between Massa and I, I've kept out of the public discussion. Now, I'll throw in my comments.

Of course, I'm opposed to the fork and would much rather see patches towards Services, but also am understanding of Massa's position, he needs specific features and he needs them immediately, which is just about impossible when there is a responsibility to other maintainers as well as users.

Its been a while since I've been able to give some time to Services, so when Massa asked for commit access and gave a list of tasks he wanted to tackle, I welcomed the help. Seeing his involvement on other projects, I had assumed he would be familiar with the patch, review, approve, commit workflow. I kept an eye on the first bunch of commits, which were mostly bug fixes and cleanup, and things seemed good. Then, I tuned out for a few days to focus on project work, came back and saw that he had been working on a few different things, with lots of these small intermingled commits, in the "local branch" fashion he described above. The big feature in these commits was OAuth integration, sprinkled with documentation, cleanup, but also method re-namings (api changes), hook renamings "hook_service" => "hook_service_info", etc. These are things that absolutely should have been discussed, and which I would definitely be opposed to had we discussed. This is why this run of work was reverted. I proposed that he instead split the work into patches so that it could be reviewed by all maintainers and possibly refined, which was I guess when he decided instead to fork (the fork was created on the same day the work was reverted and I brought up the issues).

Unfortunately, he's made lots of structural changes to Webservices vs Services, rather than just adding the features he needs, which does not make it easy to bring back into Services. I've asked him offline to reconsider the fork, or at least keep it to himself and to instead contribute back to Services. The only change I've asked is that he modify his workflow in order to ensure code quality. Even though Services is still alpha code, there are a lot of people using it, so we do have a responsibility. This is about all I can do.

Services has and would continue to benefit greatly from Massa's time and effort. What I'm ultimately hoping for here is the fork to go away and to see patches pop up in the Services issue queue, which I'll be happy to prioritize and review. I'm still unclear on what Massa plans to accomplish by making his fork public. He's been able to benefit from Services by taking the code as a base for his work, and then hurt the same project he's benefitted from by making his fork public. If he wants to make his code available to others, I feel he should do that by providing patches to Services.

Scott

Changing status back to active. Closing the issue doesn't in itself resolve it.

Christefano,

sorry. i didnt meant to close it. It was a mistake. I just wanted to change the version since i launched the first version for testing.

regards,

massa

I am in favour of trying to bring this project back to services module. I would very much appreciate not having to figure out which module to use.

I am happy to hear that brmassa is anxious to contribute his efforts to the public, and I hope he continues to do so, but maybe with more patience and understanding. brmassa I think it is worthwhile to work with snelson, to outline your proposed changes, and spend a few moments to consider how proposed code changes may affect other users, and to be willing to discuss alternatives to your suggestions. In the end, you may save yourself time in the long run, by not having to maintain this separate module.

Working with Open Source projects can be frustrating, I have a few patches in the services.module that have had no movement for months, even if they only modify a few lines of code. I also have issues for projects that I maintain that I may not have looked at for months.

I can understand both sides, but I would really appreciate to not have to keep up with changes to both projects.

I believe this module should be marked as abandoned.

At least brmassa is trying to get a usable piece of code out, so he had to split and fork the module. How else do you expect him to do it since the maintainer wants to take a lot longer and take it a lot slower to do things. Maybe if you had allowed him to do a version change for his additions, that way he can still do his thing, and the maintainer can take his sweet time doing his version.

I worked as a developer for an open source .asp portal software group four almost four years, and another group for just over one year. I did security and load testing of the code and the testing process took four weeks with the review process taking one week. I developed several mods of my own and I never took months to have patches tested to assure they met the portal websites standard. Patches dealing with security were rushed and everything else was reviewed and if accepted, submitted to the testing group and then released. Again, this was only five weeks.

I am finding it hard to grasp how long some things take to go from a submitted patch to acceptance into the code. If you submitted a patch and it has been sitting for several months and nothing has been done about it, then maybe it is time for someone to light a fire under the bottom ends of the maintainers. If it is a patch to improve the reliability or heaven forbid the security of a module, then it is imperative it be advanced faster than several months and no one has done squat with it.

I have been tracking down errors in several installations of v6.x. This testing and tracing of errors has things pointing to added modules as well as core files. These errors have an effect on vital functions of the sites, including security. I wonder if I submit patches for the modules, how long will it be before they are reviewed since the patches will be vital to fixing errors affecting a large number of users websites.

Another thing that is infuriating is, these errors your users have been getting with v6.x have been happening for quite awhile and none of the developers of the core code and the developers of modules have bothered to pool their knowledge of the php/mysql code to figured it out. The sites I worked for would not have let anything like this go on for so long and not done anything about it.

I can't help but feel that the key players of this site and the resulting developers of the modules for it, couldn't care less. I am about to the point to say screw it and go somewhere else. Yea they may not have all these cool modules, but if you can't use them, then what is the use.

Well now we have:
http://drupal.org/project/webservices
http://drupal.org/project/webservicesapi

Forking your own module now that is cool ;)

Guys,

hehehehe.

this module is the SERVER. the new Web Services API module is for clients. The D7 version of WS module will need the new WSAPI. see http://drupal.org/node/517832.

regards,

massa

Guys,

im now wokring on a new version. Even more advanced and integrated.

The objective is now merge the APIs with other modules, notably Rules (Action/Trigger advanced module). The reason is simple: calling web services is a Trigger and providing Web Services is an Action. The same API that describes "save the node" in Rules can reused on Web Services module.

Also, Web Services module will use 4 different plugins: Input, Output, Authentication and Access control. Plus 3 different classes: requests, servers and services. Web Service 1.03 already have, but 2.x will enhance even more the API documentation module. At last, WS does not keep in an infinite development mode.

As you can see, the direction that this module is taking is diverging even more from its original, Service module. Like IMCE/BUEditor/FCKeditor modules, tailored for specific situations, providing web services can also differ.

Web Services API module aims the clients. Their needs are very different from being a provider. OpenID, Twitter, Google Maps/Gmail/Bookmarks/Contacts/Orkut, Facebook and other modules can use that simple API to unify their code.

i think it stop the discussion: "yes" it deal the same problem but "no" it does not use the same means. Because there are users that are using it (including myself), i should not stop the development.

best regards,

massa

subscribe

### Leadership in Services. Nothing that the OP talks about is surprising. A year later and where are we at?

I came across this module after confusedly staring down competing projects dealing with OAUTH; which is something I'm seriously looking for. I was drawn into this discussion after suffering from a painfully slow development cycle within the JSON Server module. Another example of demand outpacing management response. The community is throwing patches all over the place, and having difficulty getting support from the maintainers.

### This project seems modernized and is powered by passion. While I don't support forking, I'd like to recognize what it has going "good" for it. Perhaps we can build a culture around it and pull together a few of the progressives that have been feeling that they have their hands tied.

I agree with you ninjay! In some cases a fork is a necessary good to ensure progress. That's one of the ideas behind the GPL.

#630244: SA-CONTRIB-2009-101 - Web Services - Access Bypass

http://drupal.org/node/630244 - SA-CONTRIB-2009-101 - Web Services - Access Bypass