I think the reality is your next 5 years as a TomEE committer won't be much 
different than your first 5 years as a TomEE committer unless you have employer 
support.

This needs to be the number one goal of everyone who wishes to see the project 
continue: push hard to get your employer to support you contributing.

If anyone would like help with that, I am very happy to lend my support.  If I 
were to try and rally everyone around one goal, it would be that.

The brass tax reality is open source is unintentionally starved out by its 
users due to policies that making consuming easy, but contributing hard.  If 
you want to leverage open source at work, the path is often easy.  If you want 
push code out to the open source, that's usually hard and requires several 
levels of approvals.

We're all developers here, so I'm sure we can see the flaw in the system.  If 
there's a give-a-penny-take-a-penny jar and your employer makes it easy to take 
a penny, but hard to give a penny there eventually won't be any pennies.

I know many of us are rather intimidated to take on any bureaucracy in our 
companies.  But we do have to ask ourselves if these practices are ethical and 
if we shouldn't at least try to push for change.

Now when I say all this, I'm not ignorant to the challenge.  I was working at 
IBM when we started working on the first version of TomEE and had to quit to 
get the permission to work on TomEE.  Even then, I only got permission to work 
on it in my spare time.  When we cut TomEE 1.0, I had to take a week of 
vacation so I had enough time to get the release out, make that little video of 
it being setup in Eclipse, etc.  I was not alone either.  Everyone else who 
helped get TomEE 1.0 out the door was in the same boat -- working after hours.

While all of that is commendable, it isn't sustainable.  It's also somewhat 
unethical.  If this is how open source is paid for (only by people working in 
their spare time), it means that our spouses, children and families are 
essentially funding the open source project.

We have to ask ourselves if that's the world we want to live in?  Where the 
open source is developed by taking time away from families instead of getting 
time from the employer who needs it?

We need to get to a point in our industry where we see the ethical problem with 
sentences like, "I can't work on Foo project, because I have a day job [with a 
company that uses Foo project]."


-David

> On Oct 11, 2023, at 2:28 PM, Jonathan S. Fisher <exabr...@gmail.com> wrote:
> 
> Speaking from my personal pov, not my corporation, and just trying to
> be honest... I love the project, it's my favorite thing to reach for
> when I need to do anything. I stick with the 8.0.x version because
> it's quite stable and I rarely run into bugs that affect me. I don't
> really see a need to have the latest and greatest JakartaEE apis
> either, as JEE8 reached quite the maturity level. I have only
> committed a handful of times a year as bugs pop up that affect me in
> the TomEE project or an upstream one, but I could reach out to things
> that are affecting other users. I'm also a little lost on how to help
> with the latest JakartaEE impl efforts; I'm not sure what needs to be
> done or where I would fit in.
> 
> I think there are barriers of entry with Tomcat, ergo TomEE. Back in
> the day, everything was "application server first", meaning everyone
> used to install Tomcat/WebSphere/WebLogic etc, then begin coding.
> Nowadays SpringBoot and Quarkus have made things "executable first",
> in which things are packed into a single jar and executed. Granted the
> one-jar TomEE plugin can do that, and that's actually my favorite way
> to use TomEE, but it's not the default behavior which I think adds a
> barrier to entry. To get on-par with SpringBoot/Quarkus, I think you'd
> need a way for a person to download "one thing" and quickly build an
> executable jar. If the "war" step could be skipped that would be even
> better.
> 
> The other barrier of entry is something I'm not comfortable helping
> on, as I have 0 UI skills, but the website and documentation could use
> a refresh to be more attractive. I hate criticizing this because I
> love the project and I know it rides on the love and sweat of many
> volunteers and friends, so please don't take this harshly.
> 
> I will say TomEE absolutely spanks WildFly, SpringBoot, and
> OpenLiberty as far as real-world startup times of complicated apps on
> a 1:1 comparison between running the _exact_ same app. It's really
> only bested by Quarkus, but Quarkus doesn't do the half of what TomEE
> plus can, so it's not really a fair matchup. Its memory footprint is
> also quite small; I have some apps that run in 32m JVMs :) These are
> advantages almost nobody is aware of, and this project has a lot to
> offer people.
> 
> I know it takes a village, but I'm willing to be a hand in the "many hands".
> 
> On Wed, Oct 11, 2023 at 2:37 PM David Blevins <david.blev...@gmail.com> wrote:
>> 
>> Hi All,
>> 
>> Wanted to share the state of this project as reported to the Apache board.
>> 
>> - https://tomee.apache.org/board-report-2023-09-20.txt
>> 
>> The short version is we do not get enough help from you to keep this project 
>> going.
>> 
>> Should we continue or should we just give up?
>> 
>> 
>> 
>> -David
>> 
> 
> 
> -- 
> Jonathan | exabr...@gmail.com
> Pessimists, see a jar as half empty. Optimists, in contrast, see it as
> half full.
> Engineers, of course, understand the glass is twice as big as it needs to be.

Reply via email to