plainblack.com
Username Password
search
Bookmark and Share

    
Goto page «Previous Page   1 2 3    Next Page»

The policy for contributions to the WebGUI core

User arjan
Date 4/12/2008 8:35 am
Views 28168
Rating -1    Rate [
|
]
Previous · Next
User Message
JT

I like this idea very much. Could this be noted as a long term objective?

Didn't I just do that?

How can we (the not Plain Black companies) help in the best possible way to achieve this goal?

Unless you're willing to develop Lift from scratch as we talked about in the other thread about Lift then there's nothing for now. But also as I mentioned in the other thread when Lift development goes back into the queue I'll be happy to notify you.



Back to Top
Rate [
|
]
 
 
koen

Could you give an example of an exception from the history and elaborate on what went well and what went not so well?

I don't want to stir up any bad blood on features that have not gone so well, so I'll talk about one of the exceptions that has worked well. Much of the stuff Martin Kamerbeek has written for WebGUI, whether for his work at ProcoliX and Oqapi or on his own, he's been very good about helping out with both in bug fixing and answering people's questions on the forums and IRC. Many others though have contributed chunks of code and then we never hear from them again.

That is clear. But has anyone ever tried really to get something in the core and then support that part?

It's nice to get the code, but it's even nicer to get help from those people after the code is in. That's part of the reason why I'm being so strict these days about code quality, POD, tests and whatnot. If PB is going to have to support it, then we want it well documented and tested to make it easier to support.

I think this is spot on in this matter. The core is the sole responsibility of Plain Black (and thus JT) and they are in their full right to accept or reject anything in regard to that.

I guess what Arjan and I, among others, are both looking for is as much clarity on what will be accepted and what will be rejected.

I appreciate very much that you are making time to respond to us and try to work with us in this matter, even if there are not much direct advantages to get out of it and even if the indirect advantages are vague and hard to measure. That is why it is so important that we know how to ask for things and how to know in advance as much as possible what to do to get things changed in ways that are advantageous for us.

If all that goes into the core has to be maintained by Plain Black, we'd better watch out very carefully about what we whish for.

Koen de Jonge - ProcoliX
http://www.procolix.com
Hosting - WebGUI - Virtualization



Back to Top
Rate [
|
]
 
 
JT

That is clear. But has anyone ever tried really to get something in the core and then support that part?

Until you no one has shown interest in trying to do that. People are generally more interested in having PB support their contributed feature. Which is fine by me, but that also means I decide whether it gets in or stays by whatever means I decide is appropriate.

I think this is spot on in this matter. The core is the sole responsibility of Plain Black (and thus JT) and they are in their full right to accept or reject anything in regard to that.

I guess what Arjan and I, among others, are both looking for is as much clarity on what will be accepted and what will be rejected.

The answers I've provided are as clear as I can be without having a specific feature/plugin/project in mind.

I appreciate very much that you are making time to respond to us and try to work with us in this matter, even if there are not much direct advantages to get out of it and even if the indirect advantages are vague and hard to measure. That is why it is so important that we know how to ask for things and how to know in advance as much as possible what to do to get things changed in ways that are advantageous for us.

This is important, and I've done my best to answer your questions.



Back to Top
Rate [
|
]
 
 
arjan

That is clear. But has anyone ever tried really to get something in the core and then support that part?

Until you [Koen] no one has shown interest in trying to do that. People are generally more interested in having PB support their contributed feature. Which is fine by me, but that also means I decide whether it gets in or stays by whatever means I decide is appropriate.

Apparently it's obvious for you that people expect Plain Black to support a contributed feature? Do you ever ask for maintenance or bugfixing? Or perhaps demand it if you are no great fan of the feature? Take SQL Form for example. I completely understand the reasons to replace SQL Form. But on the other hand: it's a pity that a major contribution from outside PB is replaced without upgrade path and without prolonged involvement. Has there been discussion about this with Procolix or Oqapi? Have they been asked to play a role in this? I don't know, but I suppose they have an interest here.

 

Kind regards,

Arjan Widlak

United Knowledge
Internet for the public sector

www.unitedknowledge.nl



Back to Top
Rate [
|
]
 
 
koen

Take SQL Form for example. I completely understand the reasons to replace SQL Form. But on the other hand: it's a pity that a major contribution from outside PB is replaced without upgrade path and without prolonged involvement. Has there been discussion about this with Procolix or Oqapi? Have they been asked to play a role in this? I don't know, but I suppose they have an interest here.

ProcoliX hasn't. SQL Form is an Oqapi infant now (I could hardly call it a baby).

Koen de Jonge - ProcoliX
http://www.procolix.com
Hosting - WebGUI - Virtualization



Back to Top
Rate [
|
]
 
 
JT
> Apparently it's obvious for you that people expect Plain Black to  
> support a contributed feature? Do you ever ask for maintenance or  
> bugfixing? Or perhaps demand it if you are no great fan of the  
> feature? Take SQL Form for example. I completely understand the  
> reasons to replace SQL Form. But on the other hand: it's a pity that  
> a major contribution from outside PB is replaced without upgrade  
> path and without prolonged involvement. Has there been discussion  
> about this with Procolix or Oqapi? Have they been asked to play a  
> role in this? I don't know, but I suppose they have an interest here.
>
I didn't ask for support from Oqapi in this place because basically as  
soon as I allowed SQL Form into the core, I realized that it was a  
mistake. SQL Form is a great system, but it doesn't meet the criteria  
for being in the core, as I said in another post. I knew we needed to  
develop something that more suited our audience.

When the SQL Form is yanked from the core in 7.5 it will be placed out  
in the contribs area so that someone can take over maintenance.  
Perhaps that will be Oqapi. Perhaps though, it will be someone who  
uses it even more than Oqapi. For example I know Knowmad Technologies  
uses it pretty extensively.  Maybe they'll want to keep up with it  
just for their own clients.


Back to Top
Rate [
|
]
 
 
patspam

I have a pie in the sky idea for Lift (the upgrade system we talked about) where we'll set up a repository so that WebGUI developers other than Plain Black can publish their WebGUI plugins (assets, macros, whatever) and then site owners, through a GUI interface can install/upgrade those plugins remotely. I think that's a much better long term approach than keeping everything in the core. That way you truly do own, document, support, and bug fix your own features.

Wouldn't the logical repository for this be the CPAN?
Patrick

Back to Top
Rate [
|
]
 
 
JT
No. It would work for macros and that's about it. Anything that needs to upgrade data needs a powerful patching mechanism and cpan isnt built for that. 

JT
On Apr 13, 2008, at 8:21 PM, <pat@patspam.com> wrote:

patspam wrote:

I have a pie in the sky idea for Lift (the upgrade system we talked about) where we'll set up a repository so that WebGUI developers other than Plain Black can publish their WebGUI plugins (assets, macros, whatever) and then site owners, through a GUI interface can install/upgrade those plugins remotely. I think that's a much better long term approach than keeping everything in the core. That way you truly do own, document, support, and bug fix your own features.

Wouldn't the logical repository for this be the CPAN?
Patrick

http://www.plainblack.com/webgui/dev/discuss/the-policy-for-contributions-to-the-webgui-core/10


--

Plain Black&#44; makers of WebGUI
http://plainblack.com


Back to Top
Rate [
|
]
 
 
arjan

Hi JT,

First of all: thanx. This helps a lot in developing some feeling for what is acceptable for inclusion in the core and what not.

The points you are making are of a different kind than my list. The requirements I've listed are true or not true. The items you mention are more interesting, since they are more policy-like.

Ultimately the final word on what does or doesn't get into WebGUI resides with me.

I know, you are the Benevolent Dictator of this project and that's no different from most free software projects. That is also why I'm very happy you're willing to clarify the more subjective things you take into consideration. I can easily apply this list to something like the UserList Yung and United Knowledge are making ready for the core now.

What percentage of the current or future WebGUI world will likely find this feature useful? Anything less than 30% and I have to have some other reason to include it. Anything less than 10% and it likely won't get included, unless it can be switched off, or easily removed so it is out of the way of your average user.

Quite clear and more benevolent than I would have expected.

Is this feature usable by our target audience with their current skill set? The target audience: normal business users (that is unless it has it's own audience, like userImport.pl clearly targets sys admins). 

I can apply this to the SQL Form for example. This is quite hard to use for this target audience. And although it's great for integrators like us, because you can do almost everything, you can probably expand Thingy to (almost) meet SQL Forms features and still have a tool that is more user friendly.

To what extend can the ability to switch off a feature compensate for not meeting this criterium? I suppose that since things like an asset can easily be swiched off, are more likely to be acceptable to the core even if they are off by default, than something big in the core of the core.

Is there a monetary incentive to include it in the core, for Plain Black or any WebGUI integrator (United Knowledge being one of those integrators)?

One could say: If there are many clients, business users, of Plain Black or an integrator that have a need for a specific feature and are willing to pay for it, this proves the first point: the current WebGUI world finds this feature usefull.

What is the maintenance cost of this feature? This is important because once it's in the core it's primarily Plain Black's responsibility to support, document, and fix bugs for it. It would be nice to think that other people in the community would step up to do it, but with a few exceptions, this hasn't been the case historically. Therefore the maintenance cost is important for us to consider.

This has a lot to do with code quality I guess. Most of the knock-out criteria I formulated are also directed to maintainability.

Is the meaning of support here, that Plain Black answers the phone if her clients call about it? Or is this point mostly about maintaining the feature during WebGUI's lifecycle, bugfixing it, and a like? And what does documentation mean here? Why not add writing a wiki-page about a new asset or feature to the list of knock-out criteria?

You didn't ask if or demand that we would maintain the Ogone plug-in for example. Why? You have no faith in it? Or do you think that it doesn't work sociable if you (have to) enforce such agreements?

If it does have something to do with support in the sense of phone-support, does that mean you would not accept a bookkeeping-asset for example? Because it would take Plain Black a lot of time to figure out how it works? Or would it be acceptable, but switched off by default?

Does this feature fit the direction I want WebGUI to go? For example, we've always focussed on business users, and perhaps someone wants to do a heavy integration with MySpace or some other consumer level service. A consumer audience is not something I'm really interested in pursuing unless it has some advantage to our target audience, business users.

I think that many contributions on the Black Blog have clarified 'the direction you want WebGUI to go'. I'm looking forward to a blog entry about the form api, the RSS from parent (why it's not the direction you want WebGUI to go), WebGUI light, etc. Personally I'm really interested in you talking about the way WebGUI could go, what you see as desirable and what not and why.

Is there a similar feature in WebGUI that could be adapted for the purpose this new feature wants to fit?

Can I translate this into: you don't want two things with (almost) the same purpose in WebGUI? Is this absolute? And when is one feature replaced by another?

For example, if I had a survey to contribute, would it not be acceptable per se, because there is one? Or would it have to be of better quality (code and user friendliness)? Or would it have to be of both better quality and have all the features of the current survey?

 

Kind regards,

Arjan Widlak

United Knowledge
Internet for the public sector

www.unitedknowledge.nl



Back to Top
Rate [
|
]
 
 
JT

Is this feature usable by our target audience with their current skill set? The target audience: normal business users (that is unless it has it's own audience, like userImport.pl clearly targets sys admins). 

I can apply this to the SQL Form for example. This is quite hard to use for this target audience. And although it's great for integrators like us, because you can do almost everything, you can probably expand Thingy to (almost) meet SQL Forms features and still have a tool that is more user friendly.

To what extend can the ability to switch off a feature compensate for not meeting this criterium? I suppose that since things like an asset can easily be swiched off, are more likely to be acceptable to the core even if they are off by default, than something big in the core of the core.

SQL Form, being an asset, is an end user application, and as such should be targeted towards a business user audience. Clearly it is targeted toward a developer audience, which is ok, obviously we have SQL Report, which is also targeted toward an end user audience. However, SQL report is in use and likely to be used by a broad range of users and sites both before and after the release of Thingy. SQL Form on the other hand, is not likely to be used by even 10% of our user-base after Thingy is available, it isn't even used by 10% with Thingy not available. As such that means it should not be part of the core. Could it be turned off, of course, but it's very existence in the core means we have to maintain it, and it's simply not worth the effort. I'm not saying it's a bad app, it certainly has it's uses and it's place. But it's not a core app. 
SQL Form is a good example of an app that I allowed into the core without fully evaluating it simply because it was Martin contributing it. Had I looked at it in great detail and given it consideration, I would not have allowed it in the core in the first place.

Is there a monetary incentive to include it in the core, for Plain Black or any WebGUI integrator (United Knowledge being one of those integrators)?

One could say: If there are many clients, business users, of Plain Black or an integrator that have a need for a specific feature and are willing to pay for it, this proves the first point: the current WebGUI world finds this feature usefull.

Actually it's backward from that. What I mean by it is, will the inclusion of the feature increase adoption, and therefore drive more business for Plain Black and other WebGUI integrators. The new commerce system is a great example of that. It's an entire market segment that we simply don't reach right now. Our existing commerce system is too limited to compete with any other systems in any serious way. Whereas the new one is designed for massive flexibility and extensibility, so it should allow us to grow what it can do, and therefore continuously increase adoption by customers seeking a commerce solution.
What is the maintenance cost of this feature? This is important because once it's in the core it's primarily Plain Black's responsibility to support, document, and fix bugs for it. It would be nice to think that other people in the community would step up to do it, but with a few exceptions, this hasn't been the case historically. Therefore the maintenance cost is important for us to consider.

This has a lot to do with code quality I guess. Most of the knock-out criteria I formulated are also directed to maintainability.

Is the meaning of support here, that Plain Black answers the phone if her clients call about it? Or is this point mostly about maintaining the feature during WebGUI's lifecycle, bugfixing it, and a like? And what does documentation mean here? Why not add writing a wiki-page about a new asset or feature to the list of knock-out criteria?

In every sense of the word. How many questions will we get on support boards and phone calls? How much documentation do we write to describe how to use it? How many bugs will be opened that we have to fix? How many RFE's will be opened to extend this thing to meet 80% of user need? How will this effect upgrades? How will this affect performance, memory usage, disk usage and IO, and bandwidth? How will this affect our hosting environment? 

You didn't ask if or demand that we would maintain the Ogone plug-in for example. Why? You have no faith in it? Or do you think that it doesn't work sociable if you (have to) enforce such agreements?

I didn't ask because I also didn't say it would be allowed in the core yet. Regardless of whether it is allowed in the core I have no doubt that additional payment methods will be useful for WebGUI users. Note that I'm also not saying that I won't allow it in the core. I need to look into Ogone and find out if it provides something that iTransact doesn't. I'm sure you have a reason for wanting it developed, so feel free to explain it. It could be that we need at least one major credit card payment gateway per continent. I of course also need to see the code, and make sure that it has no requirements that are outside of WebGUI. For example, in the US there is a payment gateway that is very popular called PayFlowPro (aka CyberCash), but it requires a C library to be installed on the server. Therefore I'd wouldn't allow it to be included in the core.

If it does have something to do with support in the sense of phone-support, does that mean you would not accept a bookkeeping-asset for example? Because it would take Plain Black a lot of time to figure out how it works? Or would it be acceptable, but switched off by default?

I'm trying to teach myself to reduce the amount of "never" and "ever" comments I make. Would I allow an accounting system into the WebGUI core? Maybe. I'd certainly have to decide if that was a good direction for WebGUI to go. It doesn't seem like a common web or intranet function. It seems like something that is usually installed as a stand alone application. But maybe there is great demand for it because Quickbooks is not web based (at least not the good version), and SQL Ledger is too hard to set up, and Microsoft Great Plains is too expensive. Maybe there is a reason for it, but I'll reserve those judgements for a case by case basis as they come up.

I think that many contributions on the Black Blog have clarified 'the direction you want WebGUI to go'. I'm looking forward to a blog entry about the form api, the RSS from parent (why it's not the direction you want WebGUI to go), WebGUI light, etc. Personally I'm really interested in you talking about the way WebGUI could go, what you see as desirable and what not and why.

Great. Keep those ideas coming, cuz it's really hard to know what people want me to voice my opinion about. I have therefore just been spouting off about whatever crosses my plate on any given day. I'll note these and use them as future Black Blog topics.

Can I translate this into: you don't want two things with (almost) the same purpose in WebGUI? Is this absolute? And when is one feature replaced by another?

For example, if I had a survey to contribute, would it not be acceptable per se, because there is one? Or would it have to be of better quality (code and user friendliness)? Or would it have to be of both better quality and have all the features of the current survey?

In general I don't want two different things in WebGUI to do exactly the same way. Now it's ok if one can be adapted to do something that the other does, but their primary purpose must be different. For example, the Collaboration System and Folders can both act as Photo Galleries, but we also just introduced the Gallery asset in 7.5. That's cuz the primary purpose of CS is to be a forum type tool, and the primary purpose of the Folder is to be an asset organizer. So it is ok to introduce Gallery which does a much better job of being a photo gallery. Likewise we have Poll and Survey. Obviously they serve two different purposes, but in some regard they can be put to similar use. If you were to come up with a new Survey, then we'd have to evaluate whether we should adopt your new survey or stick with our existing one. But I wouldn't want two survey systems in WebGUI. Not that you couldn't do a contribution so people could install yours if they wanted, I just don't want 2 in the core.

Back to Top
Rate [
|
]
 
 
     Goto page «Previous Page   1 2 3    Next Page»



© 2020 Plain Black Corporation | All Rights Reserved