How To Misappropriate and Misrepresent Other People’s Hard Work in 12 Easy Steps

Step 1. Work using an alias. Why expose your identity?

Step 2. Spend years asking the Logtalk open-source developer to implement everything except the proverbial kitchen sink, while at the same time politely declining to make any significant code contribution to all those features you find critical. After all, you’re a commercial user, with serious business to attend to. No time to fool around. In our example, the wish list includes:

  • an IDE
  • a type-checker
  • a cross-referencer
  • automatic dependency generation
  • a bootstrapped implementation
  • a code coverage tool
  • a web server
  • a sockets interface
  • unit test support (ignoring the existing one)
  • new documenting tools (as the existing ones don’t fit your commercial development requirements)
  • a revamped debugger

Step 3. Score hundreds of hours of free support, including on-line and in-situ, from the Logtalk developer. Besides saving you precious development time, you’re also learning the fine details of the Logtalk implementation, which will be quite handy in later steps.

Step 4. Plan your moves carefully. For example, make a peanuts donation to the Logtalk hosting expenses. It’s one less burger and cola, which in itself is not a bad idea. Who knows? It might become handy in the future to claim that you had gone as far as contributing financially to the original project.

Step 5. Try to dictate the Logtalk roadmap in a public Logtalk wiki. Users write wish lists; developers write roadmaps. But who cares about these fine distinctions? The important bit is that you may now argue that your “collaboration” attempts got shut down by the ungrateful Logtalk developer.

Step 6. Fork Logtalk. Forks can be a fantastic tool for collaborative development. So much that Logtalk is available not only from an open-access Subversion server but also from a git repository in a convenient public place. Of course, a fork starts as being an exact copy of the existing software.

Step 7. Take a page from Microsoft and name your fork OpenLogtalk. This will make it easier for new users to peek the most open alternative. Is dead simple: just choose the one with “open” in its name. Duh!

Step 8. Present your work as an upcoming professional alternative to the original academic and amateur one. Sprinkle the description of your fork with concepts from Software Engineering 101. Talk how you’re going to provide “high reliability” and “comprehensive documentation”. Talk is cheap; you can afford it.

Step 9. Present your work as a new implementation, while kindly acknowledging the first and original implementation. For example, write:

OpenLogtalk is an implementation of the “Logtalk language”.

The first implementation of Logtalk was by Paulo Moura.

The article “an” is a good choice as it nicely suggests “another” and “alternative”. Don’t let the little fact that the first implementation is also the only existing one, that you forked, spoil your message. Deception, after all, is an art that requires practice.

Step 10. Make cosmetic changes to your fork. Change tabs into spaces, put a tab before comment text, split files in smaller files (nothing rhymes more with “modular” than a lot of small files, even if you just end up loading all of them), remove a prefix from internal names, never mind that is there for sound technical reasons as already explained to you.

These changes are very important as they (1) make the code in your fork look different in a quick glance; (2) make the code fit your programming style (coding guidelines of the original developer be damned; it’s your fork!); (3) make it next to impossible for the original developer to pull and include your changes without lots of rewriting work; (4) reinforce the reality distortion field that you jump-started in the previous steps. As a bonus, you may get to claim later on the road the the original developer is not playing nice as he is not picking up your “contributions”.

Step 11. Innocently ask the original developer for help in understanding the source code. Put his mail replies in new files in your fork. It helps in product differentiation.

Step 12. There is no step 12. You’re already using a fork, not for collaborating, but to split. The best thing that can happen to a young programming community. Just let it roll.

P.S. If you care about Logtalk, help to spread this post and expose the troll.

Logtalk is the result of more than 12 years of hard work. Logtalk is, always have been, and always will be open for collaborations. Is not open, however, for abuse from disgruntled commercial users.

13 Responses to “How To Misappropriate and Misrepresent Other People’s Hard Work in 12 Easy Steps”

  • Victor Lagerkvist

    Sorry to hear that. While I believe that forks in general are a Good Thing my glimpse of the Github page did not reveal any redeeming features. It mostly seemed like a Potemkin village to me. Moreover the name “open” is disingenuous at best and I cannot help but feel a small resemblance to Orwellian newspeak…

  • Bob's Your Uncle

    Stealing in the age of open source: all it takes is chutzpah.

    One person, the developer, puts in the work to build a tool and support its users; a second person, the parasite, uses the time saved by not doing this work to develop a market for himself. Then, to add insult to injury, makes an attempt to exclude the original tool builder, by sleazy branding (“open,” really?) and cosmetic forking of code.

    This kind of behavior is a cancer that affects all of the open-source community: if the people who actually do the work start seeing opportunistic parasites reaping all benefits, they will eventually go back to proprietary and closed-source solutions — seriously, why be a chump by choice?

    And we’ll all be poorer in the long term for the short-term benefit of the parasites.

  • Artur Miguel Dias

    I couldn’t believe it when I heard about this. I needed to go see with my own eyes. Obviously the excuses for the fork are deceptive and extremely lame.

    What is scary is that, given enough time and effort, a parasite can have some success. The only defense is to spread the word.

    • Paulo Moura

      Lame motivation indeed. Unit tests are written treating an implementation was a black box. Developer tools such as the ones listed by this troll are preferably written in Logtalk itself using the language reflection support and the term- and goal-expansion support. Mucking around with the internals of the current implementation accomplishes nothing towards the purported goals. Smoke screens…

  • Vítor Santos Costa

    I had a look and it is indeed very strange. Anyway, I don’t think this fork will be able to put in anything measuring up to the effort Paulo has, and I don’t think it will go very far.

  • Michael Igler

    “Envy is the art of counting the other fellow’s blessings instead of your own.” (Harold Coffin)

  • Daniel Diaz

    It is a pity to hear that ! Paulo devoted so much time and effort in his system. For me the equation is simple: Logtalk iff Paulo. This does not exclude external contributions obviously, but they cannot in turn exclude Paulo ! Beyond to be a buzzword, “Open” relies on an “elegant” way to do things… What Paulo describes here is not elegant at all. I want to believe a “gentlemen agreement” is yet possible ! Else Paulo, you should inform the Perl Foundation and the FSF, you will obtain precious information.

    • Paulo Moura

      This troll’s fork does not comply with the Logtalk license (Artistic License 2.0) the last time I checked. I notified him 7 days ago to no avail. Not surprising.

  • RBT

    Actually this really is a very strange and disrespectful behavior. I’m a big of Logtalk and really appreciate all your work Paulo. How can I (or other Logtalk supporters) support you according this concern? I hope they will not be successful with their fork. Didn’t you about these plans in advance? Best. RBT

    • Paulo Moura

      Thanks for your support in spreading the word on this troll. He did send me a message saying that he was planning on forking Logtalk. I assumed that he meant a private fork, like most commercial Logtalk users do for internal customization and use (which is, of course, allowed by the Logtalk license).

  • Parker Jones


    I am the evil troll.

    I am the evil troll who has been the main supplier of bug reports to Logtalk for the last three years (just look at the Logtalk release notes). The evil troll who has contributed code (unit testing of Logtalk). The evil troll who on Paulo’s request often tested Logtalk before it was released. Yes, sure, I got good support from Paulo, but it has been working well both ways. Then Paulo got upset because I forked.

    So why fork? Am I planning to build an evil empire based on Paulo’s work? Yeah right.

    No, it’s simply because Paulo’s code is one long prolog file (16,000 lines) and I don’t understand it. When using Logtalk you get this fantastic encapsulation – kudos to him for building this – but you also lose some important features that you would get if you were using Prolog. (A cross-referencer, a profiler, Tom Schrijvers’ type-checker, and various other goodies that work with prolog). Working without these tools is a pain especially when developing large applications.

    So, my plan has been to build an experimental fork of Logtalk to understand how it works, break it into modules and hopefully expose a clear API to the main functions that would make it easier develop these tools. I chose to make my changes public, so they can be used if so desired. All my changes are easily viewable and there is nothing to prevent them going back to Paulo’s project. So what’s the big deal? And so what if I prefer spaces to tabs?

    Paulo: I understand my own wishlist doesn’t fit your objectives, that’s fine. But if you cannot accommodate other developers on your open source project and you feel threatened by a fork, then why put an open source license on it?

    Calling the fork openlogtalk wasn’t the best idea, but it just happened to be the first name that came into my head, and not some evil scheme. Apart from that I can’t see what Paulo is so upset about.

    Parker (aka evil troll) :-)

    PS. I have made all the changes you requested as per Artistic License, if there are others perhaps you should state them explicitly. FUD helps no-one.
    PPS. I am happy to supply evidence to support the above claims (assuming Paulo gives me permission to publish our exchanged emails).

    • Paulo Moura

      Dear troll,

      All contributions to Logtalk are properly acknowledged on the publicly available release notes, included in every distribution and also available here:

      These release notes go from July, 1998, when the first beta version was made to available registered users, to yesterday, June 16, 2010, when Logtalk 2.40.0 was released. In 12 years, I count 12 bug reports from you. Of course, it could have been just one. Every contribution is important and appreciated. As for as your “unit testing” contribution goes, let’s get some perspective. You took the example queries that I wrote for the examples, which I also wrote, tweaked them to fit in your custom, private unit test framework (ignoring the Logtalk library support for unit tests) and sent the result back to me. I then rewrote all the code to use a new, improved Logtalk unit test framework, which I wrote by myself from scratch.

      As I commented earlier, your justification for forking Logtalk is a smoke screen. All the necessary hooks for implementing the tools you elude about are already in place. Using the good software engineering principles that you love so much to quote, such tools should use the official, sanctioned hooks and treat the Logtalk implementation as a black box.

      About the only thing you know of my objectives is that I enjoy programming. As far as accommodating other developers, you don’t need to worry about that. You only need to know that I will not be accommodating you.

      The OpenLogtalk name is not a bad idea. Is an insult. Your OpenLogtalk wiki, still unchanged as of this writing, remains a place of deception.

      Regarding your statement that you have made all the changes necessary to comply with the Artistic License 2.0, I notified you by email 13 days ago that your public fork doesn’t comply with the license, specially section 4, which requires an explicit and clear document with all the differences compared with the standard version. As of this writing, no such document exists. Thus, the only FUD here comes from you.

      A word of advice, if I may: next time you get an opportunity to expose your point-of-view, try not to blow it. And do try to keep up. As of this writing, there 48 change sets for you to port back; I seem to remember you writing that you’re developing an implementation of the Logtalk language.