Re: JProfiler
On 07/03/2013 11:43 AM, Itamar Heim wrote:
On 07/03/2013 12:38 AM, Karsten 'quaid' Wade wrote:
> On 07/02/2013 02:33 AM, Dave Neary wrote:
>> Hi Liran,
>>
>> It appears I am alone in having concerns about this so I would go ahead
>> and request the project license as you proposed.
>
> FWIW, you can *always* figure I have concern about using non-FLOSS tools
> in an open source project. I like learning from history and past
> mistakes.
>
> Bottom line is, if people like us (and our engineering and product
> managers) don't step up to the line to deliver open solutions for our
> development needs, then we continue to fall behind
> closed-but-ready-today solutions in the drive toward deliverable dates.
>
> Every decision to purchase a closed solution instead of writing or
> fixing an open solution hurts the entire ecosystem. It's behavior we can
> expect at the corporate layer, but it shouldn't push its way up to the
> community project layer.
we aren't purchasing, we are using something provided for free for open
source projects.
s/purchase/choose/g
We all know of experiences (BitKeeper => git, etc.) where a
provided-for-free solution became a lock-in and then a trap.
Another angle is that closed software fails the good science test.
Others should be able to reproduce everything we do without needing to
obtain non-FLOSS tools.
It's also perceived as unfriendly toward other FLOSS projects when we
don't use what they provide and help it fix the delta to the closed
solutions. These projects are more of our friends normally than the code
vendors.
similarly, i'm for using the coverity solution for scanning our
code(we
are also using the open findbugs, but coverity has things not covered by
findbugs (it actually uses findbugs now).
It's a potentially non-fallacious slippery slope - we can draw a
reasonable chain of events from the 'small' act of choosing a single
closed solution to something fairly bad for the project.
The bottom line is that if a project chooses to use a closed solution,
it should be after a lot of due diligence that includes making sure it's
not better (for many reasons) to improve a FLOSS-but-not-good-enough
solution. The project should then put it on the roadmap to get that
closed solution replaced via some method - waiting for another project
to mature, working up an open solution in parallel, etc.
https://www.theopensourceway.org/wiki/How_to_loosely_organize_a_community...
- Karsten
--
Karsten 'quaid' Wade
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
Attachments:
- signature.asc (application/pgp-signature — 255 bytes)