Is it ethical to ask SDNers to code for free on a community project?

[Former Member]

As some of you may be aware, Anton Wenzelheumer has been writing a lot of beautiful php code down in the Scripting Lanuages forum, in response to problems I've been posing in the bioinformatics section of the SAP wiki.

But now, I have about 100-200 hours of straightforward but complex code that has to be written in perl or php - no fancy web scripting - just read a file in, analyze it in various ways (no regex - all comma-separated variables), and output one or more files. (But the analytic routines are very interesting from a technical point of view.)

So, suppose there are 20 folks here at SDN who know perl and/or php as well as Anton knows php.

That means that the job could get done if each one of these folks did 10 hrs for free.

Is it fair to propose a project of this size to the SDN community?

What I mean is the following.

Even if 20 people actually signed on for 10 hours each, would it be fair to ask them in the first place?

Please note that I'm not asking if it would be "appropriate". In my opiniuon, it's definitely "appropriate" because SDN not only has a scripting languages forum, but also actively seeks code samples that people can learn from. So in this case, the code samples would teach folks how to solve a wide variety of very complex analytic problems in perl or php.

But what do you think of the "fairness" question?

djh

[Former Member]

Hi djh,

In my opinion, if the piece of code is going to be useful for a wide range of SDNers seeking solutions to their problems then it is a very fair activity. Infact, I think that is one of the main ideas of collaboration. I will only be too happy to get myself involved in such a community project. Unfortunately, I have a different area of expertise and can not meet your challenges. But I always look forward to your tricky questions and the various replies to it in CC.

The only thing that irritates me is, some SDNers asking to do their job free of cost (which has no additional technical value or nothing too complex in it).

P.S: If there is a community project where my expertise in SAP XI/PI could be of some help, count me in.

Regards

Jaishankar

[Former Member]

Hi Jaishankar -

It's a pleasure to make your acquaintance - thank you very much for taking the time to respond.

You wrote:

In my opinion, if the piece of code is going to be useful for a wide range of SDNers seeking solutions to their problems then it is a very fair activity.

I couldn't agree with you more on this point, and in fact, the project that I need to be coded illustrates your point for the following reason.

Suppose you have 100 materials in MARA with material BOMs containing 200 maximal components each. (A maximal component = a component which does not itself breakdown into further components, i.e. any "maximal" or "terminal" vertex in the tree-graph of the BOM.)

Furthermore, suppose that each of the 200 maximal components of each of the 100 BOMs have 20 "allowable alternates" under "interchangeability & substitutability" relationships defined inside SAP. So you have 20 * 200 * 100 "alternates" in all, or 400,000 "allowable alternates".

Now, since you're a skilled and conscientious MM/IM guy, you notice that some of these 400,000 "allowable alternates" are used a lot, and some are used not at all.

Furthermore, you suspect that this is because your Purchasing Director is getting kickbacks from certain companies that supply certain of the "allowable alternatives" - namely, the ones that are being used a LOT more than the other possible "allowable alternatives". But you only have anecdotal evidence to support this hypothesis, e.g. you've seen this Director playing golf and eating out at fancy restaurants with sales reps of certain suppliers who happen to be supplying the "allowable alternatives" that are seeing a lot of use.

So how do you "prove" your suspicion?

Well, if you've had at least one course in basic stat or scientific methodology, you know that you can never "prove" your suspicion - you can only disprove the null hypothesis.

In this case, the null hypothesis is that frequency of use of an "allowable alternative" does not correlate with supplying vendor.

And to DISPROVE this null hypothesis, you have to perform one or more statistical experiments to show that the distributions of supplying vendors per "allowable alternative" are NOT mostly normal (bell-curve). That is, if the distributions of supplying vendors per "allowable alternative" are almost all normal (with a few exceptions due to easily identifiable "odd-ball" external factors), then it's clearly NOT the case that certain suppliers are supplying more than their expected share of "allowable alternatives" because they're paying kickbacks to your Purchasing Director.

But guess what?

When you write the ABAP to perform the required experiment(s) to disprove the null hypothesis, you've written exactly the code that I need written in perl or php.

And therefore, it follows vice-versa that if an SDN collaboration group writes what I need in perl or php, then SDNers will not only learn a lot of perl and php "by example", but they will learn how to write ABAP programs that do the same thing.

AND - as an EXTRA ADDED benefit, they will learn that although perl and ABAP seem very different on the surface, they are similar in one very very important respect: they both allow and support hashed itabs of virtually unlimited size, depending of course on system resources. (I don't know about php support for large hashed tables, but I assume it's probably there since Anton likes to write in it.)

And as I have pointed out many times at SDN, this feature of ABAP is one of the most important features that make ABAP such a powerful programming language. (For example, in one of my earliest blogs here at SDN, I showed how you can easily redo ANY ancient SAP ReportWriter program by using an ABAP OO tree to represent your "control breaks" and a dynamic ALV grid that you feed from a hashed detail data itab whose multiple-field key corresponds to the different levels of your tree; this allows you to "chase" your detail deta upwards, rather than downwards in the usual way using AT's for control breaks.)

Anyway, I realize that all of the above was a very long-winded way to say that I agree with what you said, but I wanted to "go on" at length because I personally find it fascinating that so many ERP MM/IM problems have architectural similarities with bioinformatic problems. Maybe the saying "it's all in our genes" means more than people think - maybe all MM/IM information has to be encoded in ways that are basically similar to the way information is encoded in our genes for a very simple reason:

it's our genes that are manufacturing the MM/IM data encoding machines - namely us (or at least the part of "us" who are system designers in Walldorf!)

Best regards

djh