Frustrated by OSS Submissions Process; Am I the Only One?

[machineghost]

I just had an extremely frustrating experience with the Sugar CRM maintainers, and I was wondering if it was an anomaly or "par for the course".

After I wasted an hour or so trying to setup email through Sugar with an invalid port (my company uses HTTPS), I realized that Sugar should provide the default HTTPS port, if you indicate that you are using HTTPS, the exact same way it already does with the default HTTP port. So, I filed a bug and provided a patch (as I had already fixed the issue in our installation of Sugar so that my users wouldn't face it). It took forever to get a response, then I had to fax in some paperwork, it took awhile longer and ... my patch was rejected

Now if there was some legitimate reason for the rejection I would have no issue, but the reason cited was that people could have non-standard ports. But of course, that is just as true of HTTP (which Sugar does provide the default port for) as it is of HTTPS, and my patch in no way interfered with setting a custom port (all it did was set the default HTTPS port when the user switched to HTTPS, IF it was still set to the default HTTP port).

So in other words, the person who rejected my patch didn't even look at how it worked, or look at how Sugar already works, they just arbitrarily decided to reject it. And I find that REALLY frustrating; it's certainly going to discourage me from ever submitting a patch again.

But now that all that venting is out of the way, what I really want to do know is: is this normal? Does anyone else have similar stories of the OSS community giving the maintainers valuable contributions and having them rejected for bogus reasons? Or has everyone else's experience been more positive (and maybe I just got the rookie bug inspector on my case)?

[SugarDev.net]

It's only logical for you to feel what you are feeling right now. You have committed a nice patch which supposedly makes the product a better, friendlier one, which is one of the goals of SugarCRM. Still, it was rejected. There have been rejections of my patches or my bugs while they addressed real problems with little or no room for discussion about the issue or its solution, yes. But we also have to realise that there may be considerations which are invisible to us as outsiders. On the other hand, Sugar could try and be a bit more forthcoming with the reason of a rejection because as proved above, the willingness to make patches which end up in a black hole is pretty limited when your contributors are all on someone's payroll.

[kebabman]

I don't think it really matters what OSS project it is you contribute to. If a patch gets rejected there should be a good reason for it and also room for discussion on how it can be improved/altered in order to make it acceptable. It's always a kick in the teeth when something like this happens and it definitely puts people off contributing any future efforts.

[matthew]

I think it's fair to say the submission process for patches is broken. It's my job and I'm the one who probably told you to email or fax your contributor agreement.

Here's the bad news - the broken contribution process is only part of a larger problem. Currently SugarCRM's build process creates it's products (CE, PRO, ENT) in a way that we cannot put our Community Edition source code in the open. Therefore the contribution process is complicated and has issues like you have experienced.

Here's the good news - We are well aware of it and we working on it. I literally had a meeting yesterday with the CIO, the heads of engineering, and various IT people at Sugar to stop this problem. It's not a change we can make over night and it will fundamentally change how we develop. We are going to take incremental steps over the next year to get a better process in place.

With that said, with the release of 5.5 GA, I intend on taking the first step to getting Sugar's source in a place where people can make changes and interact with the SugarCRM engineering team in a more collaborative way. Right now GitHub is looking like a good option to do this with.

Finally, regarding the contribution agreement process. It pains me to ask anyone to send a fax this day in age with their signature. However, thanks to different laws of different countries, it's a necessity. The bottom line for that process is, it's out of Sugar's hands as long as SugarCRM goes "by the book".

[eggsurplus]

Just so it doesn't seem like this always happens I've generally have had a positive experience with code submissions. Of course, there may have been one or two that got rejected but it seemed to be with good reason.

It is a pain to do the fax thing though. Signing it once should (maybe is now?) be enough.

[salesagility]

I think it's fair to say the submission process for patches is broken. It's my job and I'm the one who probably told you to email or fax your contributor agreement.

Here's the bad news - the broken contribution process is only part of a larger problem. Currently SugarCRM's build process creates it's products (CE, PRO, ENT) in a way that we cannot put our Community Edition source code in the open. Therefore the contribution process is complicated and has issues like you have experienced.

Here's the good news - We are well aware of it and we working on it. I literally had a meeting yesterday with the CIO, the heads of engineering, and various IT people at Sugar to stop this problem. It's not a change we can make over night and it will fundamentally change how we develop. We are going to take incremental steps over the next year to get a better process in place.

With that said, with the release of 5.5 GA, I intend on taking the first step to getting Sugar's source in a place where people can make changes and interact with the SugarCRM engineering team in a more collaborative way. Right now GitHub is looking like a good option to do this with.

Finally, regarding the contribution agreement process. It pains me to ask anyone to send a fax this day in age with their signature. However, thanks to different laws of different countries, it's a necessity. The bottom line for that process is, it's out of Sugar's hands as long as SugarCRM goes "by the book".

Matthew ... it's encouraging that Sugar is actively addressing its community processes ... I sense that this is part of a wider community engagement strategy. If I'm correct, it's the best news to come out of Sugar for a long time.

[machineghost]

First off, thanks all for your responses!

eggsurplus - I'm glad to hear that someone else has had a more positive experience.

SugarDev.net and kebabman - I completely agree with both of you. Of course the Sugar organization will need to reject patches sometimes, and the patch submitters will not always agree with that decision, but even so the organization needs to do what it feels is best for Sugar. I understand that. But at the same time, when there's no "dialogue" in the process, it's extremely frustrating for patch submitters because there's no way for them to respond to/address the issues that caused the rejection (and this ultimately just discourages participation).

matthew - Thank you so much for taking the time to post. First off, on the fax thing, it really wasn't that onerous; the issue for me was just that, after I had jumped through the legal hoops AND taken the time to find the problem AND create the patch in the first place, I received a (IMHO) ill thought out rejection, with (seemingly) no course of redress. But, as salesagility wrote, if you (and others at Sugar) truly are moving towards greater community involvement, then this is indeed "the best news to come out of Sugar for a long time."

As companies like Canonical (the makers of Ubuntu Linux) have shown, a corporate entity selling added features on top of an open source community's efforts can be incredibly successful, and the company/community can exist together symbiotic-ally. But if the corporation takes that community "for granted" (so to speak), the relationship becomes more parasitic, which never ends well for the community. So I wish you the best of luck in convincing "the powers that be" at Sugar to embrace the value they can get from the community, rather than stifling it.

As for my patch, I responded to the bug, and now I guess I just have to wait and see. But eggsurplus's and mathew's posts have given me hope that reason may still prevail, so thanks guys (and again, thanks to everyone who responded).

P.S. On the legal requirements of the fax thing, I hope you're basing this off the requirements of non-US companies, because the (US) company I work for deals in "electronically signed contracts", which I can assure you do not require a fax to be valid.

P.P.S. One idea on the "greater community involvement" front would be to to give source control access to people outside the company. If you allowed leading community members to accept patches I think this would go a long way towards making the Sugar project feel more community- and less corporate-driven.

P.P.S. Another thought would be to offer more support options for OSS users. My company gets one support question per year, and that's all we're ever going to get because we have no interest in the proprietary Sugar stuff, and the only support option for companies like us is the "one question per year" one. If we could have instead paid more for a better level of support (without having to pay for the proprietary junk) we would have happily thrown more money at you guys when we first got started with Sugar.

(At this point, since I've finally gotten everything stable, I'd have a hard time justifying that spending to our CFO, but I still think improved support options would be valuable to other new Sugar OSS users, or possibly someday for us, if we ever start doing more advanced stuff with our Sugar installation).

[Angel]

Interesting conversation...

My 2 cents...not directed at anyone specifically, just general observations...

Personally, I think part of the problem is the definition of "open source" itself. The variances in how people define it tend to lead to some frustrations, etc. A good gauge of this phenomena is the plethora of open source licenses that are out there, the result of the differing view points on what it actually means.

In my career, I've been around a number of both proprietary and open source software packages, either for reasons directly related to my work or just general curiosity. My only real expectation of any "open source" package is that I can access the code. Anything else beyond that is icing on the cake as far as I am concerned.

Other folks, on the other hand, think it is sacrilegious to even use the term "open source" if the project doesn't conform to everything FSF says, etc.

Point being, those are drastically different interpretations of what it means to be "open source" and what responsibilities are expected of the authors and community.

When it comes to Sugar, I think the term is more in line with how I interpret "open source": the code is available, everything else is icing on the cake.

I, however, would add that people often times assume a little too much about the "icing on the cake" and misjudge Sugar's intentions. Sometimes this leads people to erroneously believe that Sugar is somehow not interested in working with the Community, or that they are somehow purposely setting them at arm's length, and that in turn will lead some to frustration.

Nothing is perfect and Sugar is no exception. In the context of this discussion, it is worth highlighting that Sugar, over time, indeed has moved more towards the FSF side of things. The adoption of GPL3 to replace its proprietary license with the 5.0 release is a good example.

Further to this, it is also important to bear in mind the market that Sugar is targeting. CRM technologies are targeted at sales and marketing folks more than anything else, not necessarily the tech crowd like us. Those folks tend to only care about how they can go about improving their business and their bottom line, they don't care about philosophical discussions like this one.

From my perspective, I would rather see focus being placed on ensuring the application meets the need of the market better than any other product, as opposed to spending too much energy figuring out how to make it more open source friendly as that's not what is going to grow the user base, whether we like it or not.

BTW, as a side note on the issue of buying support...that option was available, but done away with, not entirely sure why, but I would assume that it wasn't too popular and the costs probably didn't justify it.

[kebabman]

From my perspective, I would rather see focus being placed on ensuring the application meets the need of the market better than any other product, as opposed to spending too much energy figuring out how to make it more open source friendly as that's not what is going to grow the user base, whether we like it or not.

Whilst I agree with your sentiment here about meeting the needs of the end user I do not totally agree that focussing on the OSS friendly aspect will not help to grow the user base at all. If the process of accepting patches included a bit more dialogue with the authors of rejected patches then it might end up in the patches being included. This in turn would make Sugar more complete as a system and therefore increase the user base as these patches would add functionality that some users would use.

I am not saying that the Sugar team should totally focus all their efforts on the OSS side, far from it. All I think is that if they are providing an OSS option then it would be nice to dialog with the users that are giving them code to use in their offerings.

[Angel]

I am not saying that the Sugar team should totally focus all their efforts on the OSS side, far from it. All I think is that if they are providing an OSS option then it would be nice to dialog with the users that are giving them code to use in their offerings.

Well stated. My main point is that too often, people fail to acknowledge that Sugar can't be the FSF based company that they would want in their dreams.

Like I said, nothing is perfect, and over time, Sugar has proven they're willing to try different things. Sometimes they work out for the best, sometimes they don't (Express)....