So much to talk about, so many good thoughts.
I think there's a path forward, and I definitely would vote to keep this
project alive.
- I am interested in developing and helping the project move forward. I
hope that Carlos is also interested in putting in some work to make this
project happen. Personally, sure I'm busy but I don't feel like there's a
lot of work to be done to make this project releasable and do the things
necessary to make it pick up and bring in more people. The core code base
is already highly functional. I know it works because I worked on an
application that consumed its services at AT&T back in the day. There's
just a bit of work to smoothing out the process of installation and running
it with a standard servlet server. And it needs documentation.
- I'm a little disheartened that we haven't heard from Pam Dragosh.
She's the original visionary behind it, and I'd very much like to have just
a little bit of her time to help us transition it the rest of the way to
Apache (not coding, but a transfer of knowledge to aid documentation. And
maybe it's just all implemented according to some spec, but I'm not aware
of whether the XACML spec somehow specifies API endpoints, etc). And
there's an entire admin API that is difficult to reverse engineer.
- I work for a company that may be willing to donate some work in
exchange for a bit of recognition. I am going to the Fluent conference in
early March, and will be meeting the CTO of my company there. I'm going to
use that opportunity to try to get him on-board with us helping this
project. I think it makes sense for both the project and the company.
- I agree it's probably the wrong thread to talk Maven vs. Gradle, but
if Gradle has some advantages (which it sounds like it does), maybe moving
to Gradle is what needs to happen. Sure, it's only 1%, but that's where
this project is. We're basically that 1% of the way away from being able
to release this, with the exception of documentation (and to some degree
promotion).
- We obviously need some basic project management work to get done. We
need a JIRA instance up and running for us, and we need some tasks put in
there. Who can volunteer to make some/all of that happen? If no one else
wants to volunteer, I can do it (although if Apache already has an instance
for us to use, I don't know where it is). And who could edit the main page
to create those links? Can Carlos and I be promoted to make more things
happen?
- We need a roadmap. I'm not big on roadmaps personally, but I have a
basic idea of what it needs to be for the short term:
- Smooth out the build process.
- Get AT&T out of anywhere it remains in the code.
- Version 1.0 Release
Any other thoughts?
On Tue, Feb 9, 2016 at 7:28 AM, Sinnema, Remon <[email protected]>
wrote:
> Attracting outside interest will be hard when it's unclear what people can
> work on.
>
> The project page doesn't provide a lot of information:
> http://incubator.apache.org/projects/openaz.html
> The "website" that it links to gives 404.
>
> There is no link to the issue tracker. Emmanuel mentioned JIRA, but where
> is it?
> I couldn't find a roadmap either.
>
> The code contains no guidance about the various sub-projects, how they
> relate together, and what their status is.
>
> Give this situation, if I wanted to contribute, I wouldn't know where to
> start.
>
>
> BTW, the old project page still exists but doesn't link to Apache:
> http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page
>
>
> -----Original Message-----
> From: David Ash [mailto:[email protected]]
> Sent: maandag 8 februari 2016 22:42
> To: [email protected]
> Subject: Re: [DISCUSS] - Retire OpenAz?
>
> I think it hasn't seen much activity over the past two months because it's
> been a holiday season. I know most of the AT&T people take most of
> December off (once upon a time, I was one).
>
> It has a lot of work to be done before it's functional and even remotely
> mature, and we're not going to see a lot of outside interest until it gets
> there.
> * The Admin part is crucial, and it hadn't even been ported over (I ported
> it myself, still need to fork in github and do a pull-request).
> * There's a shortage of documentation. To the point that it's unusable.
> * It's complicated enough that its difficult to come up with the
> documentation.
>
> Now, sure there seems to be a shortage of interest but I say give that
> time. XACML is not a thing of the past, it's still part of the future.
> Organizations and software developers are still slowly moving to XACML --
> it is the best authorization solution in existence to my knowledge, and
> fits nicely into a modern auth stack with SCIM, JSON Identity Suite, OpenID
> Connect, and OAuth. (
> http://www.slideshare.net/nordicapis/1415-twobo-nordicap-istour
> ). Most developers still aren't using an external authorization solution
> because they are building highly-coupled monolithic software that sucks.
> And honestly, there aren't a lot of other free open source options. The
> only alternative I see that is any good is WSO2's Identity Server (which is
> vastly superior to this product, but hey that's an opportunity in some
> ways). If this project really succeeded, it would at least allow
> developers of open source systems to build better, more modular software.
>
> The main problem I see is that AT&T still has most of the knowledge and is
> able to put very little effort behind it. We need Pam's team to write up
> some high quality documentation (particularly for the API's) and release
> that information.
>
> The other problem I see is there's kind of a lack of vision as far as I
> can tell. We need someone in the lead that has the time to craft a vision
> for what this product should really be. When you look at WSO2's Identity
> Server, you immediately start realizing the possibilities -- things that
> this project haven't even touched yet.
>
>
> Thanks,
>
> David Ash
>
>
> PS. I'll put in a pull request for my port of the Admin interface.
>
>
>
> On Mon, Feb 8, 2016 at 9:59 AM, Emmanuel Lécharny <[email protected]>
> wrote:
>
> > Le 08/02/16 16:53, Carlos Perez a écrit :
> > > Hi guys,
> > >
> > > While I completely understand the reasoning for the discussion to
> > > retire OpenAXZ, and to be completely honest I was surprised it took
> > > this long), it would be a real shame to see it just fade away into
> oblivion.
> >
> > I Agree.
> >
> > >
> > > That said, what does happen when a project never makes it to a TLP?
> >
> > From Apache POV, not a lot. We just shut down the mailing lists, and
> > close the repos (no more writes allowed).
> >
> >
> > > Does
> > > it have a chance to be resuscitated later if it is deemed worthwhile
> > > and has more interest?
> > It's always a possibility. A very remote one, I have to say. The fact
> > that in almost 2 years the project hasn't be able to attract any new
> > contributors, and that almost no activity has been seen from the
> > initial contributors make it unlikely that the project could make a come
> back.
> >
> > In 10 years, I haven't seen that happen. Not once.
> >
> >
> > > Does the license revert back to AT&T?
> >
> > Good question. I can ask [email protected] about that. The fact that it didn't
> > make it to a TLP might be relevant. For TLPs, the code base has been
> > granted to The ASF and remains so, same for the name.
> > >
> > > XACML is a complicated spec and I can¹t say that I fully understand
> > > it yet, but I think it solves a real problem (I just regret not
> > > having the time personally to help push it along).
> >
> > That's the main issue : the fcat that it's a complex code base might
> > be intimidating for many of the potential users. But IMHO, would it be
> > really a critical brick of many IT systems, it *would* have attracted
> > developpers. That raises the question of XACML as a useful technology.
> > It as been around for more than 10 years now, and I'm not sure that it
> > captured a lot of interest. But that may be just me... (and I *think*
> > it could have been a big hit years ago. Not so sure nowadays.)
> >
> > Thanks !
> >
> >
>
