Anybody else hate PR reviews?

March 31, 2021

billburke flame bait 2 Comments

I’ll start by introducing some flaim bait:

PR REVIEWS ARE WORTHLESS!

How often are you waiting days or even weeks for a PR review? And when it is about to be approved you get a merge conflict and have to start all over again? How often are PR reviews subjective rather than objective? How often are you subjected to anal-retentive suggestions that have nothing to do with the efficiency or effectiveness of your code and all to do with somebody’s pet peeve?

Nobody ever reviews my tests

I’ve been paid to write code for 31 years now. Its never good to deal in absolutes like always or never or everybody or nobody, but I can honestly say that in the last 3 decades my tests have NEVER EVER been reviewed by ANYBODY. The only time I ever get a comment on testing is if I submit a PR that doesn’t have ANY test code. This is the biggest reason why I think PR reviews are completely worthless. Your testsuite is the most important part of your project. Without a good testsuite that CI green checkmark you waited so long to get has a lot less meaning. Without a good testsuite, developers become superstitious and fearful about changing any code. If PR reviewers aren’t reviewing the tests, what the fuck is the point of the review?

PR Reviews slow down development for little gain

PR reviews almost always slow down development and can even bring it to a standstill. I’ve experienced this at multiple companies so its not just a symptom of open source development at Red Hat. At the last company I worked at, you’d dread any inter-team PR as you would wait for weeks, even months for a PR review to get on somebody’s Sprint board. On the Quarkus team given the nature of open source development, the sheer volume of PRs is overwhelming for those that can actually review and approve PRs.

The results of the PR review backlog are merge conflicts, unintegrated code, and often paralyzed development. Every day you wait for an approval increases the probability of a merge conflict causing additional work you didn’t plan for. As PR’s pile up you end up with a bunch of unintegrated code that has not been tested together, with a CI green checkmark that could be days or weeks old. If you need to continuously work on the same part of the code base, your PR backlog can prevent you from working on bugs or improvements as you are waiting on your code to become part of master.

As a result of this, you find yourself looking for people that are rubber stamp reviewers. “Hey buddy, can you just approve my PR? The sprint ends tomorrow.”. We are all guilty of it at some point or another. Obviously, this defeats the purpose of the PR review.

PR reviewers look for low hanging fruit to deny your PR

The PR review process is a chore for developers. A good review takes time. Time most developers don’t have. This is especially true for cross-team PRs where the target team often does not have your PR on their sprint board. Because of this time squeeze, reviewers look for low hanging fruit to deny your PR so they don’t have to approve it. This is especially common for PRs that come from external non-team members as trust hasn’t been established. Because of the lack of time for a comprehensive review, they look for a simple subjective suggestion to bump you back to the CI/approval queue. i.e. “I don’t like the name of this method, class, or field.” Sometimes I think reviewers feel compelled to find something wrong. Like they aren’t doing their job if they don’t (especially younger devs).

PR reviews discourage iterative development

I’m old. I spent a significant number of years without the PR review process in place. What I’ve found personally is that I rarely do much iterative development anymore because the CI/PR review process takes so long. In the past I’d be fixing a small bug and find a piece of code or API that I think was poorly written and just rewrite it. Refactorings often create bigger PRs. The thing is, developers hate reviewing large PRs as it takes a lot of time. So, any large PR might spend a lot longer in the PR review queue. Because of this, I don’t do refactorings much anymore because a long review wait queue makes merge conflicts inevitable.

How to fix the problem?

How can we fix this PR review bottleneck?

Approve and open up a new issue instead

If the PR passes CI, is tested correctly, but you believe the code could be better, instead of demanding a change, open a new ticket and schedule the code improvement for later. Better yet, assign the new ticket to yourself.

Automatic approval after fixed time period

If a PR has the CI greenlight, but sits un-reviewed. Approve it blindly after a fixed time period.

Stan Silvert suggested this in the comments

Suggest, not demand subjective changes

Identify when you are asking for a subjective change. Be honest, aren’t the majority of PR reviews just subjective suggestions? Instead, just comment on your suggestion, or just use Github and code a change to the PR itself (Github allows you to autocommit this).

Introduce an “Approve if CI passes“

I think Github supports this, but, have a PR approval if CI passes option to PR requests. Automate it if possible.

Review tests

Read what my PR is trying to accomplish then review my test code to see if it is comprehensive enough. If you don’t have time to do that, then you are better off just approving the PR and removing yourself as a bottleneck.

Trust your test suite and CI

To speed up the PR approval you have trust in your test suite and CI builds. If your test suite sucks you are going to be more superstitious and fearful of changes to your codebase and will look for any excuse to deny a PR. If you are a project lead spend a Sprint or two every once and awhile and focus on improving your testsuite and CI builds. Introduce backward compatibility tests. Performance regression tests. Review code coverage reports. If your testsuite is strong, its ok to just gloss over PRs, or just blindly approve PRs from trusted individuals.

Encourage asynchronous, pre-PR feedback, but without Slack

As a PR submitter, you will ease a lot of pain if you talk about your design before you begin coding. Talk about API changes you want to make before getting to work. Get some input. You’ll save a lot of CI/PR review time if you do some of this upfront.

You’ll be even happier if you fish for asynchronous feedback. Instead of zoom, try sending out an email about what your ideas are. This allows people to give you feedback on their own time.

Why not just drop the PR review?

I’ll conclude my blog with some controversy: Why not just drop PR reviews altogether. Their trouble is worth more than their value. PR submitters look for rubber stampers. Reviewers don’t review tests: the most important part of your PR. Let your testsuite and CI become your automated implicit PR reviewer.

If you’re too scared to make this leap, maybe develop a circle of trust where you have a subset of developers that can be trusted to self-approve and merge their PRs. Before git, PR reviews, and CI, back in the old JBoss days of the 2000s, our open source developers earned commit rights. If you earned the trust of the project leaders, you earned the right to commit and merge whatever you wanted. Granted, in those days we also didn’t have Continuous Development, but maybe there is some middle ground we can reach.

/votetokick pr-reviews

Finally, please note that this blog is tagged as “flame bait”. I’ve received some internal emails with people that are relatively shocked I could even suggest or question the value of the PR review. Maybe I’m just trying to show people that they need to improve/streamline their review process or just get out of my way and trust me? 🙂

Translating “Right tool for the job”

April 25, 2014

billburke flame bait 7 Comments

When I hear somebody say “Right tool for the job” I cringe.  The acid in my stomach starts to churn.  My blood pressure goes up.  I just feel like lashing out or screaming.  Why do I get this reaction?  Its a simple, logical statement.  Sounds like great advice, right?  In my experience though, “right tool for the job” is often code for something else.  Its an often used, cliche excuse to hide hidden motives.  So, let me translate for you the true meaning of “Right tool for the job”.

  • There’s this cool fad new language that everybody is talking about.  I’m going to use this new language to implement a new feature even though nobody else on my team will be able to maintain it but me.  Even though the code will hard to maintain because I’ll be experimenting with every possible new feature of the new fad language I’m using. Thus: New language XXX is the RIGHT TOOL FOR THE JOB!.
  • Everybody is talking about this new cool No SQL stuff, but I’m stuck coding RDBMS with Hibernate.  Thus: No-SQL DB XXX is the RIGHT TOOL FOR THE JOB!
  • This job sucks and I need to train myself in a new technology so I can get a new job. Thus: Technology XXX is the RIGHT TOOL FOR THE JOB!
  • My product/project is missing a key fundamental feature that a competing, more mature technology has had for years.  I can’t say that this competing older, mature technology is better, I need an excuse so instead I say: You need to pick the RIGHT TOOL FOR THE RIGHT JOB!

Consultants are even more notorious for this.

  • I need to make myself invaluable to this company so I can keep billing high rates for myself and my underlings.  So, I will find a technology that nobody in this company has experience. Thus, Technology XXX is the RIGHT TOOL FOR THE JOB!
  • I need to train a bunch of my new consultants in a new technology.  Better to charge this training on somebody else’s dime.  Thus, Technology XXX is the RIGHT TOOL FOR THE JOB!
  • I need to drum up business, sales are lagging.  So, I’ll create a new methodology and pay some Thought Leader to bless the methodology.  Then I’ll get my best speaker to troll all the developer conferences touting this new methodology.  Thus, Methodology XXX is the RIGHT TOOL FOR THE JOB!

Admit it! You see this happening everywhere.  We’ve all done it at least once.  But no more for me!  Just like I want to purge swearing and cursing in front of my kids, I want Right Tool for the Job out of my vocabulary as well.  If you ever hear or see my say this phrase, call me a hypocrite.  Flame me.  Chastise me.  Remind me of this blog!

 

 

Worst fans in the league

October 16, 2013

billburke flame bait, sports Leave a comment

New England Patriots Fans Suck!

As a 20 year season ticket holder, in my experience, Pats fans are the worst fans in the league.  They leave early, they are not loud.  They boo the team with even the slightest mistake.  You even get yelled at sometimes for standing up and making noise for the Defense.  The drunken “pink hats” are often screaming Brady’s name when the Pats are on offense.  The worst culprits are the premium seat wusses who empty their seats even it is marginally cold or sprinkling a little.  Seems people are more interested in getting wasted, impressing their girlfriend, getting on the big screen, getting on TV, and/or beating the traffic instead of watching the game.  It sickens me.  The best part of going to the games is that I get to spend time with my father and sister.  Sometime in the far future when he is unable to attend games, I’ll seriously consider giving up my tickets and watch games on TV instead.

That being said, I am ashamed of myself as I am one of these shitty Pats fans.   At the end of the Saints game, we were guilty of leaving our seats after Brady threw his interception in the final 2 minutes.  As we were crossing the bridge, we saw that the Pats would get the ball back, so we ended up going to the standing-room only area in the endzone and watching the final drive on the big screen.  Was still a cool experience, but I wish we had never left our seats.  I WILL NEVER LEAVE MY SEATS AGAIN!  I PROMISE!

NSA’s anonymous spying

August 14, 2013

billburke flame bait 5 Comments

I just don’t get the uproar with NSA spying on internet traffic and websites. Most of what NSA is doing is data mining which is inherently anonymous, I can’t see how any of this has anything to do with privacy or freedom for that matter.  Sure, it creates possibilities for abuse, like blackmailing somebody that doesn’t want to come out of the closet or is having an affair.  But wouldn’t strict laws with strict penalties, and strict procedures prevent such abuse?

For example, police need a court order to wire tap a phone.  Couldn’t we just treat the results from data mining as we would a phone?  The program would provide a list of potential suspects.  FBI could check the suspects vs. public records and such, and then go to a judge for a court order to open up the details of the data mining done.  Furthermore, if we have strict laws that prevent the CIA from using this digital spying for blackmail or other shady dealings, other nations wouldn’t have much to bitch about.

Given that we’re in an age of social media where a lot of what we do on the Internet is public knowledge, what’s all the pew pew about?  Google et. al. are already doing this anonymous data mining to provide highly targeted ads.  Why is it more acceptable for Google to do this, than for the NSA to search for crazies that want to fly planes into buildings, bomb marathons or shoot up a school?  For myself, so much of what I do is in the public what do I care if some data mining program is parsing and analyzing my emails?     I also don’t think we’re giving up on freedoms to make ourselves safer.

We must trust in our institutions that they are either benevolent or that there are appropriate checks and balances in place to prevent abuses.  If these checks and balances are missing, its time to legislate them into existence.  I think there is a happy medium where we can make ourselves safer and put the adequate safeguards in place to prevent a total Orwellian society.

Mocks are a Mockery

May 1, 2012

billburke flame bait, opensource 17 Comments

There were some interesting side conversations going on in the comments of my Java EE wins over Spring blog.  In particular, a few people were arguing over the value of Mocks.  I always considered Mocks a bogus pattern.  Only time I ever use them is when I’m initially starting a project and I don’t have full implementations of a particular subsystem and I need to test that something works.  You see to me, your GIT master branch, or your SVN trunk is a sacred place.  I fully believe in the idea of continuous integration.  But to have a pure Trunk, you have to test your code, as close as possible, to the target environment it is supposed to run in.  Mocks go counter to this idea.  And give you false sense of security.

My colleague, Stan Silvert said it best:

When you DO use mocks you are testing in an environment that is biased toward a passing test. An artificial environment will always make invalid assumptions about the behavior and stability of that environment.

What you end up with is a (hard to maintain) mock library that allows your tests to pass and gives you a warm feeling that you’ve done a great job. But you are fooling yourself.

The ONLY reason to use mocks is when test execution in the real environment is unacceptably slow. This used to be the case quite often. But with frameworks like Arquillian and super-fast startup times for app servers this is no longer a frequent concern.

I’ll end with an even more radical assertion. The difference between integration testing and unit testing is purely semantic. Even the smallest, most focused unit test pulls in a lot of the environment (JVM, OS, etc). In-container testing just pulls in more of the target environment and allows you to find more errors sooner.

Test in the real environment and get results that are truly valid. Stop kidding yourself with mocks.

Personally, I’m a very paranoid person when it comes to development.  Earlier in my career I did a lot of demos and live coding in front of an audience.  When you’re in this type of environment you live by the mantra that anything that can go wrong will.  So, when rehearsing, you always mimic as much as possible what your setup will be.  I carried this paranoia to Iona (an Irish company), when I worked on Orbix there.  We had a rule, that if even one test (integration or whatever) failed, you were awarded the Guiness Penalty.  If you broke the build, you had to buy every one on the team a pint of Guiness.  IN this environment, Mocks are a waste of time, both in build CPU and in coding time as you still had to run integration testing before you committed anything (unless of course you just wanted an excuse to have a few beers).

So unless a particular integration test is ungodly slow, don’t use mocks.  Stan again, said it best:

…the days of the 2 hour in-container smoke test are over.
Since mocks no longer provide much of a speed advantage their use is outweighed by the fact that they give you a phony environment, maintenance headaches, and false confidence.

But you do touch on a truth about testing that a lot of people miss. The purpose of testing is to uncover errors. And you will uncover more errors in a real environment than you would in a mock environment.

With projects like Arquillian and fast boot up times like AS7 (1.75 seconds on my laptop), there’s no need to mock anymore.

Typical example of why dynamic languages suck

August 30, 2011

billburke flame bait, python 10 Comments

Awhile back I ranted against using dynamic languages like Ruby, Python etc.  Recently, I’ve been using Python as a way to test Resteasy’s SMIME integration.  It was an extremely frustrating experience that would have been much better if Python was statically typed.  Why?  Well, take a look at this documentation for doing SMIME with Python and M2Crypto.  The problem was is that the examples are interacting with Python’s mail API. I needed to be able to send SMIME over HTTP.  So, I needed to understand the M2Crypto API a little bit better.  If you look at the example code, you have no idea which additional methods are available, and more frustratingly, when types of objects these methods return.  The auto-generated javadoc-like docs for M2Crypto were even less helpful.  What I had to end up doing was diving into the M2Crypto codebase to figure out exactly what was going on.

Moral of the story?  Programming in dynamic languages can be a lot of fun.  But when you run into APIs you’re not familiar you’re pretty much at the mercy of the documentor.  If the documentation sucks, you’re pretty much up shit creek and forced to dive into the code to understand what is going on.

Should REST be Organic?

January 27, 2011

billburke flame bait, REST 7 Comments

Since our kids were born years ago, my wife has generally been pretty Organic crazy.  The Organic food movement was created so that we don’t “poison” our bodies with food grown and treated with harmful pesticides and chemicals, that don’t introduce dangerous genetically modified seeds or growth hormones, and finally, contribute generally to society as a whole by promoting sustainable farming that doesn’t deplete or damage the environment.

From Movement to Certification

Organic food and farming started out as a movement, but quickly turned into a branding and certification effort.  Many farmers and companies found that following strict organic principles was expensive and added to the cost of the goods they produced.  While many customers were willing to pay the extra cost involved to avoid “poisoning” their bodies, still many others are more interested in saving money now and worrying about the long term consequences to their bodies and environment later down the road.  So, some companies would avoid pesticides, but still use genetically modified seeds, and call their products organic.  Or milk companies wouldn’t use growth hormones, but still use non-organic feeds for their livestock, and still call their products organic.

To fight this pollution and misrepresentation of organic principles a branding and certification effort was introduced so that each product on the market could be officially approved as organic or not.  Organic food customers would know what to expect from a product by seeing this brand on their packaging.  If you wanted to sell organic products, you’d have to be officially certified and inspected by a third party.

Is REST following Organic’s path?

Roy Fielding, the father of REST, has the same expectations that organic food consumers have.  When something is deemed RESTful he has certain expectations that have to be 100% fulfilled.  Its very understandable as Roy deals with Web standards, they have to scale, their going to be used by millions.  The stability and usability of the Web are too important to propagate flawed protocols.  Roy says in his PhD:

While mismatches [to REST] cannot be avoided in general, it is possible to identify them before they become standardized.

So, maybe Roy should trademark REST, brand REST, and promote the creation of an official organization that can bless an application or API as RESTful much like we have an Organically Certified label.  Let’s do a tiny thought exercise on this…

One of the consequences of heading down this route is that REST evangelists will lose the Web as their prime example of REST in action.  While the HTML and HTTP standards and specifications will be a great example of REST in action, most of the applications on the Web don’t follow the strict criteria of REST (a static web page is not an application).  As Roy states, its hard to avoid mismatches in the RESTful style, even if you try.  This is especially true if you’re building a distributed interface for a legacy system.  The rest of us will lose a lot of language and vocabulary to describe our apps if REST is branded/certified.

Well…You may be laughing (or fuming) about the idea of branding and certifying REST.  The thing is though, often, when you interact with the REST community you get condescending comments like:

Then do not call it REST. It is that simple. And saying that some academic has not written a line of code detracts from what you are saying. REST has a clear enough definition. XXXX  (insert whatever here) is not RESTful, so don’t call it so!!

You get this sort of interaction when a thought, API, or interface breaks or bends a RESTful principle AND you want to still use REST to name and/or describe your thing.  Reactions like this is very akin to treating REST as a certified brand rather than a style.

Expectations are just not the same

The thing is though, the expectations of IANA, W3C, and people Roy Fielding are very different than the average application developer.  There’s really two main reasons why a developer initially is attracted to REST:

  • Simplicity.  You can use a RESTful interface without having to define a WSDL document, generate stubs, and download (or pay for) some complex middleware stack or library just to implement a “Hello World” example.
  • “Lightweight” interoperability.  Because HTTP is everywhere, if you write a RESTful interface, it should be usable in most languages and platforms without much effort (i.e. iphone, android, python, Ruby, Java, Perl, etc…)

Sure, there are a lot of other goodies you get when you learn more about REST architectural guidelines and start applying them, but these two reasons, IMO, are the reason app-developers initially look into REST.  W3C, IANA, etc. have different expectations, though, as they are defining standards that the Web will be built upon.  A screwup here can have a much more far reaching affects on things compared to messing up an application that can usually be refactored over time.  The domain REST is going to be applied to should have a direct correlation on how critical we should be of the interface.

Focus on benefits and consequences instead of definition

While strictly following REST works for Web standards, its just not always feasible to follow them religiously in everyday applications.  After all, REST is a style and set of guidelines, not a set of laws or, gasp, a branded certified trademark.  Instead, people should be allowed to use REST to name and describe themselves without harassment.  Instead, critics should focus on the consequences of a specific app or API not following a specific RESTful constraint and the benefits if they did modify the interface to follow the guideline.

I think we’ve all had negative experiences with trying to follow an architectural principle (REST, OOP, or whatever) religiously.  I think most of us realize that focusing on delivery to market through multiple iterations and user requirements and feedback is much more important than whether we religiously follow a specific guideline.  The easy answer is “Then don’t call it REST!”, but we’d have a very limited vocabulary in software engineering if this mantra was followed with every new architectural style that was created.

Freetards vs. Apple

January 14, 2011

billburke flame bait 6 Comments

Recently I’ve complained a bit about the righteousness of Apache and, at times,  its negative effect on open source and Java.  Well, recently the GNU Freetards got into the act against Apple.  It seems a piece of GPL licensed software, VLC, was published by iTunes, and one of the original developers of VLC sued Apple to remove it from iTunes stating that the GPL conflicted with the DRM licensing required by anything distributed by the App-store.  It seems that the DRM licensing forbids reverse engineering of downloaded apps, while GPL allows (and encourages) it.

Its the spirit, not the fine print, that matters

The spirit of the GPL, IMO, is that once something is open source, it stays open source, derivative works and all.  If you want to link it with your software, then your software must also become open source.  Denis-Courmont’s beef with Apple is just semantics.  You don’t need to be able to reverse engineer VLC binaries, because the source is available.  You can fork VLC into your own app and post it on the Apple App-Store with no problem.  I’ve also heard that the DRM forbids more than 5 copies of your downloaded binary to be distributed on various devices, which also breaks the GPL.  So what?  You can always download, for free, another duplicate binary.

There are consequences to fundamentalism

The first and obvious consequence to the actions is that iPhone users can’t get VLC anymore, unless of course they have the technical know-how to jailbreak their phones (which the vast majority don’t).  The second is that all the hard work of the developers who created the iPhone app is thrown out the door.  I don’t know about you, but I’d be pretty pissed.  Third, and most important is, does this screw the rest of us developers that want to distribute GPL/LGPL software for iPhone/iPad?  Which pisses me off, because, I prefer the LGPL, and more importantly the spirit of that license, not the fine-print.

I think a better approach would have been to be less confrontational and more cooperative.  For instance, I bet Red Hat and other large companies, if you asked, would be more than willing to officially ask Apple to change their policies to be more GPL friendly.  There are a lot of different ways to pressure Apple, while at the same time, not screwing the rest of us who want to distribute GPL/LGPL based software on iTunes.

This general approach to life that ideals and principle should always trump compromise gets us things like crappy health care bills, deadlocked legislatures, poor union contracts across various industries, and probably a lockout for the NFL season next year.  Hopefully this unwavering/uncompromising idealism that seems to permeate our society as of late is just a fad.  One can only dream…

Hopefully Apple does the right thing

Finally, hopefully Apple revises its terms of use to be GPL, LGPL, and open-source-license friendly.  But, IMO, iTunes and the App-Store is their baby.  Its a privilege, not a right to use it.  (Java falls into the same boat, unfortunately).  Sady, we can’t expect this change to happen.  In the meantime, we probably have to use a different license to distribute open source software on iTunes.  Thanks Denis-Courmont…

Apache damaging to Open Source

May 19, 2010

billburke flame bait, opensource 10 Comments

I just read an interesting blog by Savio questioning the value of LGPL.  IMO, he has something right, the OSS license chosen for a project is not that important as far as adoption or business goes.  The most important driver for OSS is and always has been the brand of the project.  Like their commercial counterparts, how the project is perceived by consumers is what drives both adoption and business.  So, I agree, LGPL doesn’t add a lot of value.  But, it goes both ways, the Apache license is also not that important either.

If you boil it down, the distinctions betwen GPL, LGPL, and ASL are pretty much meanlingless to most consumers of OSS.  How so?

1. The viral nature of GNU bases licenses is only triggered when binaries are distributed.  Most consumers of open source do not distribute software publicly.

2. LGPL is also not an issue for ISVs as long as they leave the binary as-is.  Its viral nature is triggered when the project is both modified and distributed.

So, when you take these two points together, the number of people affected by the differences between GPL, LGPL, and ASL become fewer and fewer.  GPL does not affect > 90% of OSS consumers.  For LGPL, the number of people actually affected by the license becomes a number that you can probably count on one hand.  The ones affected are the ones who actually want to use derivatives of the project within their own competing initiatives that are not LGPL-based.   So, do you see how meaningless it truly is?

Why making these distinctions is damanging

This all brings me to my final point.  The whole push by Apache.org and its minions that ASL is the one true license is just damaging to open source.  When you consider the handful of individuals affected, you got to question the motivation for it, especially when you match it up to LGPL.  The thing is though, highlighting the differences only helps those handful of people that have selfish motives and/or want to exploit OSS for commercial gain.  Believe me I’ve lived this.

Back in 2003, a group of JBoss contributors tried to fork both the JBoss code base and the JBoss business.  IMO, their motives were mostly financial.  They wanted a bigger piece of the pie that Marc Fleury was unwilling to give up.  Whether or not they were right to do this is besides the point, there are good arguments on both sides, and whats done is done.  They initially derived themselves from the JBoss codebase, went to Apache, and thus Geronimo was born.  We complained that their derivation was both a copyright and LGPL violation.  In the end, they started over from scratch (don’t think the LGPL had value for JBossians back then?  think again!).  When Geronimo 1.0 came out, their feature set was vastly inferior to JBoss so their push was that it was the only Java EE implementation that was ASL.  That LGPL was scary and the only way to get over the fear was to use ASL-based projects.  IBM got into the act when they purchased Gluecode (and all the Geronimo developers) and embraced Geronimo as their children’s edition of Websphere.  Again, the main push was that Geronimo was ASL based.

We then come full circle to 2010 with history repeating itself (well, sort of).  You have Tom Bayerns leaving Red hat for Alfresco to create a competing BPM engine.  Now, I consider Tom a friend, and I completely understand his reasons for leaving Red Hat.  That being said, launching a new open source BPM engine with the premise being “we want to create something in ASL because it is better for our business”, is not the way to go about it.  Again, it smacks all over of having nothing but the zero-add of the ASL distinction.  And, is just completely irresponsible.

If you are an Apache guy, you should be appalled by behavior like this when it happens.  Individuals and companies that use ASL as a weapon to further their own selfish and commercial needs should be castigated and called out instead of championed as the reason why ASL is so cool and LGPL is so bad.  Respect the choice of other open source developers, propagating the myth that an ASL project is superior to a LGPL project because of license distinctions does nothing but hurt the open source movement as a whole.  We need to stop eating our own.

Finally, I just don’t want to bash on Apache and ASL.  Joining the GPL revolution isn’t so hot either.  The fear of GPL virality is used extensively in the dual-licensing ploy of commercial interests.  Think MySQL.  For me, I would never pick GPL, because I believe in the freedom of letting ISVs distribute my stuff as-is.  As for LGPL vs. ASL?  I could care less, it really doesn’t matter.  You don’t see JBoss caring so much either.  Drools is still ASL as well as a number of other jboss.org projects.

Anyways, have fun with this, and remember taking any one position to seriously is unhealthy.

Google’s ‘worries’ are just a ruse

April 15, 2010

billburke flame bait 13 Comments

I think this Google announcement that they are worried about Java being rudderless is just a ruse.  I guarantee they are planning to take what they’ve done within Android and position it as a new language to replace Java.  This “the sky is falling” statement by Josh is just setting the stage for it.  They’ve pretty much done it with every non-standard library (do their own thing), so, IMO, setting the stage for a new language is right up their ally.  Plus,  creating your own language is the ultimate expression of ego and we know there’s lots of it at Google.  So, when Google announces their replacement for Java, remember, I told you so…

Older Entries

%d bloggers like this: